Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:ALF/Requirements Management"
(→Links and Impacts) |
(→Links and Impacts) |
||
| Line 34: | Line 34: | ||
Impacts are '''not''' relationships between attributes. They are '''not''' relationships between single versions of requirements. | Impacts are '''not''' relationships between attributes. They are '''not''' relationships between single versions of requirements. | ||
| − | Example: Requirement A. | + | Example: Requirement A.Version0 says "Every push button has to be green." Requirement B.Version0 says: "The login screen has to be light red for the corporate identity and name and password have to be entered." |
The two requirement does not impact each other. | The two requirement does not impact each other. | ||
| − | If requirement B gets changed to B.1: "The login screen has to be light red for the corporate identity and name and password have to be entered. Then a login push button has to be clicked to start login procedure." then an impact has to be | + | If requirement B gets changed to B.1: "The login screen has to be light red for the corporate identity and name and password have to be entered. Then a login push button has to be clicked to start login procedure." then an impact has to be created from A to B. From that moment on A will impact B. |
When requirement A gets changed to A.1 "Every push button has to be green with a light red border." then requirement B (in its actual version B.1) has to be reviewed. The change of A may impact B in a way that it has to be changed again, too. | When requirement A gets changed to A.1 "Every push button has to be green with a light red border." then requirement B (in its actual version B.1) has to be reviewed. The change of A may impact B in a way that it has to be changed again, too. | ||
Revision as of 07:20, 14 August 2007
Attributes and Requirements
From the description I take it that a Requirement Type pre- defines a particular set of attributes. Is that the case?
Qualitypark: Yes, that's true. One quality issue of requirements is their completeness. Thats why for every type of requirements a pre-defined set of attributes is given which have to be filled to proof the requirements completeness. Different requirement types may have different quality criteria and for that they have different attributes.
Change Proposals
Are change Proposals allowed on any version of the requirement or only the current version?
Qualitypark: The goal is to achieve a set of valid, non-conflicting requirements. Historical versions are stored for traceability reasons, but only the current version is valid. Any change proposal is a request to change the requirement within the actual environment of requirements. Practically there is no need to change a version that is already outdated.
Links and Impacts
From the description, an impact appears to be a link between two requirements that expresses some kind of releationship between the attributes of one requirement and the attributes of another requirement. The relationship between the attributes is unclear.
Is the link bi-directional? Can I see the link from the Target ore must I create a reverse link/impact?
Are impacts modeled between RequirementTypes or are they created dynamically on Requirement instances?
How are the attributes in an impact linked (eg one to one, one to many, many to many)
Can two requirement instances have muliple impacts btween each other or only one (in each direction)?
Qualitypark:
Impacts are not relationships between attributes. They are not relationships between single versions of requirements.
Example: Requirement A.Version0 says "Every push button has to be green." Requirement B.Version0 says: "The login screen has to be light red for the corporate identity and name and password have to be entered."
The two requirement does not impact each other.
If requirement B gets changed to B.1: "The login screen has to be light red for the corporate identity and name and password have to be entered. Then a login push button has to be clicked to start login procedure." then an impact has to be created from A to B. From that moment on A will impact B.
When requirement A gets changed to A.1 "Every push button has to be green with a light red border." then requirement B (in its actual version B.1) has to be reviewed. The change of A may impact B in a way that it has to be changed again, too.
The same way it is possible that an impacting requirement gets changed in a way, that it does not impact some of its formerly impacted requirements any more. The impact can be deleted.
Basically there are links between the single versions of the requirements. In the example above there is a link between A.0 and B.1 and another link between A.1 and B.1. If requirement B gets changed because of the change of A and version B.2 is created then a link will also be created between A.1 and B.2.
So the link between the requirements versions is not really bi-directional. Depending on the direction it marks single historical versions of one requirement as being impacting to versions of another requirement or as being impacted by versions of another requirement.
Usually impacts are defined to describe how the requirements get developed/refined from one (more common) type of requirements to another (more special) type of requirements. So the impacting requirement and the impacted requirement must not have similar attributes.
Impacts are binary: either one requirements impacts another requirement or it does not impact the other requirement.
If two requirement impact each other so strongly that they basically are one unit then their content should be merged into one requirement to satisfy requirements quality criterias.
May be a constraint should be added, that impacts can only be defined between requirements of different types?