Jump to: navigation, search

ALF/Requirements Management

< ALF
Revision as of 04:24, 25 August 2007 by Alf.qualitypark.de (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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 requirement

To change a requirement means to change at least one of the attributes of the requirement.

The validity of the actual Current version of that requirement ends and a new version for the requirement will be created with the attributes requested and become the new Current version. The 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 deletion. The Impacts of that requirement will end because of the requirement doens't exist any more. They must not be terminated explicitely.

Propose change against a requirement

Internally a proposal against a requirement will be created. 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. Internally new Versions of the requirements have to be created which would become the Current versions and an impacting Link has to be created from the Current version of the first requirement to the Current version of the second requirement.

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. Internally new Current versions of the requirements have to be created and the impacting link of those requirements has to be deleted.

Schema

Schema

Service WSDL

ServiceWSDL

Event WSDL

EventWSDL