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 "ALF/Requirements Management"
(→Create new requirement) |
(→Change requirements current versions content) |
||
| Line 119: | Line 119: | ||
=== Change requirements current versions content === | === Change requirements current versions content === | ||
| − | To change a requirement means to change at least one of the attributes of the requirement. The validity of the version of that requirement ends and a new version for the requirement will be created with the attributes requested. | + | To change a requirement means to change at least one of the attributes of the requirement. The validity of the version of that requirement ends and a new version for the requirement will be created with the attributes requested. Internally it will become the '''Current version'''. The web service has to maintain all '''Impacts''' of the requirement from and to other requirements that also were valid for the last version. That means, that the internal '''Links''' have to be created between the '''Current version''' of the changed requirement and all '''Current versions''' of the requirements which were impacted by the former version or that impacted the former version. |
| + | |||
=== Delete requirement === | === Delete requirement === | ||
A requirement may be deleted because it is not valid any more. So its validity ends at the time of the delition. | A requirement may be deleted because it is not valid any more. So its validity ends at the time of the delition. | ||
Revision as of 04:15, 25 August 2007
Contents
INTRODUCTION
The Requirement Management Vocabulary focuses on the management and development of requirements. This is done during preparation of activities to achieve goals. Requirements management and development is the method to define and to refine all conceptual information detail of a target to be achieved before starting the activities to reach the target.
Differently from "simple" database management tools in requirements management the history of the requirements is essential. It has to be possible to describe and to store the reason of every change of a requirement or its impacts to the environment of other requirements.
ASSUMPTION
Requirements management is the process to elicit, manage and develop requirements. It is not responsible for the context the requirements are used in. While requirements themselves always are raised against a target to be reached, the requirements managements goal is to assure that the requirements raised are complete and accurate and in its overall unity without conflicts.
OBJECTS
Requirement
A requirement consists technically of a set of Attributes. The requirement itself also includes the complete history of the changes of these attributes from the creation of the requirement until its deletion.
Version of a Requirement
The version of a Requirement is the set the of the Attributes of the requirement at a point of time. A version always belongs to a requirement.
Every version has a time interval of validity. All versions of a requirement create a non-overlapping in time sequence.
Usually one or more attributes of two versions are different. Everytime an attribute was changed a new version will be created.
Current Version
The Current Version of the requirement is the last Version of the Requirement. It is actually valid and it's validity did not end yet. For most of the applications which communicate with requirements only the current version is of interest.
History of a Requirement
The line in time of all Versions of a Requirement is the requirement's history.
Attribute
Every Requirement consists of attributes that describe the properties of the requirement. All versions of one requirement have the same attributes. But usually the content of at least one attribute is different for two Versions of a Requirement.
The single attributes of a requirement can be of different data type (e.g. Text, Numeric, . A requirement can contain a file attachements as attribute, too.
Links to contents outside the requirements management may be attributes, too. Because the linked content could change independentely from the requirement such a change would not be part of the rquirements history and has to be used carefully.
Type of Requirement
Every requirement has a certain type. The Type of the Requirement describes, what kind of information is stored in those requirements. Requirements of different types usually have different sets of Attributes. Requirements of the same type have the same Attributes.
Impact
In requirements management the impacts of information on each other are managed, too. The meaning of one requirement impacting another requirement means that by change of at least of one of the Attributes of the first Requirement one or more Attribute of the second Requirement may change. The impact from one requirement to another has to be set explicitely.
Link
A link marks the fact that between two Versions of Requirements exists an impacting-impact-relationship. It refers to the Impact that was defined between the Requirements. The impacting link describes that the source version impacts the target version, that the target version is a result of the analysis of the source version.
Links can exist only between versions of requirements that exist at the same time.
Most of the applications which communicate with the requirements will only be "interested" in the current versions of requirements and their links. In the result for the external applications only the actually existing impacts are of interest.
Change Proposal
A change proposal is a suggestion for a change of a Requirement. Change proposals also can be created to propose a new requirement.
The Change Proposal contains a complete set of Attributes for a requirement.
It is the responsibility of the requirements manager to edit a requirement as a result of the review of the change proposals and the current Version of a requirement. A requirements manager can accept a change proposal as is or he can reject it.
The acceptance of a Change Proposal creates a new Current Version that then is part of the history of the requirement.
Activ Change Proposal
A change proposal is active until it is accepted or rejected.
Comment
Comments are common remarks to a Version of a Requirement. Any requirement can be commented with a random number of comments. Comments are added to Versions of Requirements.
EVENTS
Events are information about activities within the RM tool emitted to the ALF.
Requirement was created
Internally the first version of a requirement was created. An event has to be emitted to the ALF in this case. If we assume that for most of the communicating applications only the current version of a requirement is of interest then it is enough to follow up the "Creation of a requirement".
The ALF event has to transport all the information needed to determine the web service flow started by the event. e.g. - Type of requirement - Identifier of the requirement - Existing attributes' names - Attributes' contents
Requirement was changed
Internally a new version of a requirement was created. An event has to be emitted to the ALF in this case. If we assume that for most of the communicating applications only the current version of a requirement is of interest then it is enough to follow up the "Change of a requirement".
The ALF event has to transport all the information needed to determine the web service flow started by the event. e.g. - Type of requirement - Identifier of the requirement - Existing attributes' names - Attributes' contents
Requirement was deleted
The ALF has to be informed if a Requirement was finally deleted. If a requirement is deleted it's versions still remain in the pool of managed requirements. The validity of the current version ends at deletion time and no newer version can be created. All impacts from and to the requirement end at that time and new impacts cannot be defined.
Impact was created
During the creation of new versions of requirements the existing links between the versions are copied from the old version to the new version. So the requirements versions keep linked even if there are new versions.
The ALF has to be imformed if an Impact was created to follow up this event with all affected applications connected to the ALF.
Impact was deleted
The ALF has to be informed if an Impact was deleted. From that event on the two requirement formerly connected by an impact are no longer impacting one to the other.
Comment was added
ALF has to be informed, if a Comment was added to a Requirement.
Change Proposal was raised
The ALF has to get the information if a Change Proposal was added to a Requirement. More than one Active Change Proposal may exist for a Requirement.
Change Proposal was accepted
If a Change Proposal was accepted internally a new Version of the Requirement will be created. Though the ALF will be informed about that event as a "Change of requirement" anyway an information has to be given if this happened through the acceptance of a proposal to eventually react to the application that raised the Change Proposal.
Change Proposal was rejected
If a Change Proposal was rejected the ALF has to be informed to react to the application that raised the proposal.
SERVICES
The service can be used by the ALF to respond to other applications events or requests.
Create new requirement
To create a new requirement into the pool of managed requirements means to create the first Versions of the requirement.
Change requirements current versions content
To change a requirement means to change at least one of the attributes of the requirement. The validity of the version of that requirement ends and a new version for the requirement will be created with the attributes requested. Internally it will become the Current version. The web service has to maintain all Impacts of the requirement from and to other requirements that also were valid for the last version. That means, that the internal Links have to be created between the Current version of the changed requirement and all Current versions of the requirements which were impacted by the former version or that impacted the former version.
Delete requirement
A requirement may be deleted because it is not valid any more. So its validity ends at the time of the delition.
Propose change against the current version of a requirement
A new version of a requirement will be created either as the first of a (historical) line of requirements or as the next version of a requirement. This version will be marked as proposed. If the proposal is not against an existing requirement the type of the requirement has to be given.
Comment requirement
A comment will be added to the requirement.
Set impact
This means to define the impact from one requirement to another requirement. A link between the current version of the first requirement and the current version of the second requirement will be created.
Delete impact
The impact of two defined requirement may be deleted because one of the requirements changed in a way, that they don't impact each other any more. The source and the target requirement have to be given and the impact between them will be deleted, if exists. The link between the current versions of the requirements, that impact is deleted, will be deleted, too.