Difference between revisions of "Talk:ALF/Requirements Management"

Revision as of 07:30, 22 August 2007

Requirements Management

Attributes and Requirements

[Tim Buss] 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

[Tim Buss] 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

[Tim Buss] 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.

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. Then these impacts can be deleted.

Basically because of the impacts there are links created 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. If for any reason B gets changed to "No login necessary." then the impact from A can be deleted and no more links will be created between the versions of A and B. The already existing links (between the old versions) remain.

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?

[Tim Buss] I don't understand the reason for imposing this restriction. From an outsider's perspective, I would expect it to be quite likely that Requirements of the same type would impact each other!

[Tim Buss] On link direction: So is it true to say that links may be physically bi-directional because it is possible for both Requirement A and Requirement B each to know that Requirment A is linked to Requirement B but that the link is logically directional since it expresses the fact that "A impacts B" rather than "B impacts A"? If you want to express "B impacts A" then you would need a second link in the opposite direction

[Tim Buss] On links and versions: I'm confused because you say first that "they are not relationships between single versions of requirements" and further down you say "because of the impacts there are links created between the single versions of the requirements". Do you mean by this that once a link between two requirements is created, that same logical link will exist on all subsequent versions but if it is removed it is only removed from the current version?

updateRequest vs ChangeProposal

[Tim Buss] I'm a little confused by the "changeRequirement" service call and the concept of "ChangeProposal. From the description, the "change" service updates a requirement directly without changing its version whereas changeProposal is a copy of the current version with changes. A changeProposal must be "accepted" at which point is it becomes the current version.

For a particular Requirement instance, can there be mulitple outstanding ChangeProposals or only one ?

There are also separate Events for Requirement "changed" and changeProposal "accepted" and I assume the requirement "changed" event is only raised for a direct update and the changeProposal "accepted" event is raised when a changePropsal is committed as the current version of the Requirement.

It seem odd to me that ther are two mechanisms to update a Requirement, on versioned an one not, so I wonder if this is the correct interpretation. If not we need to clarify this.

It would be simpler if any committed change only came as the result of an accepted "ChangeProposal" since the model would be easier to keep consistent. The current model allows direct change so we need to be concerned about consistency in the presence of multiple updaters gien that we don't have ACID transations available to us.

Qualitypark: In the vocabulary there is no updateRequest defined, neither as an event nor as a service. One of the main functionalities of requirements management is to maintain every change and also the reason of the change. Direct changes of a version of a requirement should not be allowed.

The change proposal is an object raised against a requirement (in its actual version) that has to be reviewed by the requirements manager in person. He/she decides wether to accept or to reject it. A change proposal may be rejected but its content is used to edit the requirement.

In the history a change proposal has to be shown as "Change proposal" version (accepted or rejected!) just to know that there was one and the acception of a change proposal would create a new version with the content of the change proposal.

It is true: the event "Change proposal accepted" may not be very meaningful since a new version will be created and all service work flows will be started that have to be started at this event.

But it can be necessary to "inform" the proposing application (or person) that the proposal was rejected.

At the same time the "Change requirements current version" may be meaningful e.g. to "inform" the requirements management about status changes. (e.g. requirements implementation was tested using the test application)

Why No Service Operation for "acceptChangePropsal" etc.?

[Tim Buss] There is currently no service for "acceptChangePropsal" etc. so I didn't add them. However it seems to me that accepting a change proposal might, quite reasonably, come as the result of an related issue being processed by som issue managment tool. At the very least I would see the need for some kind of external "approval" even if the actual transition to "accepeted" must be performed within the Requirements Manager.

Linking to a "Requirement" page

[Tim Buss] In the ALF POC it became evident it wouldbe very usefule if a tool has a means of displaying its "object" via a web page that may be referenced by an URL. The URL can be dynamic but should be long lived and should present and html read only view of the object (the Requirement say).

ALF itself does not currently specify any such thing but it does strike me as useful and something we may want to consider here.

Use Case section?

[Tim Buss] It would be good to add a Use Cases section to the wiki to discuss and illustrate the expected useage.