Requirements Management
• The process of managing change to the requirements for a system
• The principal concerns of requirements management are:
• Managing changes to agreed requirements
• Managing the relationships between requirements
• Managing the dependencies between the requirements
• Requirements cannot be managed effectively without requirements
traceability
• Who suggested the requirement, why the requirement exists, what
requirements are related to it and how that requirement relates to
other information e.g. design, implementation, documentation
CASE tools for Requirements Management
Requirements management involves the collection, storage and
•
maintenance of large amounts of information
There are a number of CASE tools available designed to support
•
requirements management such as:
A database system for storing requirements.
•
Document analysis and generation facilities to help construct a
•
requirements database and to help create requirements documents.
Change management facilities which help ensure that changes are
•
properly assessed and costed.
Traceability facilities which help requirements engineers find
Stable and Volatile Requirements
● Type of Volatile requirements
• Mutable requirements
• These are requirements which change because of changes to the environment in
which the system is operating
• Emergent requirements
• These are requirements which cannot be completely defined when the system is
specified but which emerge as the system is designed and implemented
• Consequential requirements
• These are requirements which are based on assumptions about how the system will
be used. When the system is put into use, some of these assumptions will be
wrong.
• Compatibility requirements
• These are requirements which depend on other equipment or processes.
Requirements Change Factors
• Requirements errors, conflicts and inconsistencies
• Evolving customer/end-user knowledge of the system
• Technical, schedule or cost problems
• Changing customer priorities
• Environmental changes
• Organizational changes
Requirements Identification
Essential for requirements management that every requirement should have a
•
unique identification
Requirements Identification Techniques
•
• Dynamic numbering
• Some word processing systems allow for automatic renumbering of requirement depending on its
chapter, section and position within the section
• Database record identification
• When a requirement is identified it is entered in a requirements database and a database record
identifier is assigned.
Requirements Storage
Requirements have to be stored in such a way that they can
•
be accessed easily and related to other system requirements
Possible storage techniques are:
•
In one or more word processor files - requirements are stored in
•
the requirements document
In a specially designed requirements database
•
Word Processor Documents
Advantages
•
• Requirements are all stored in the same place
• Requirements may be accessed by anyone with the right word processor
• It is easy to produce the final requirements document
Disadvantages
•
• Requirements dependencies must be externally maintained
• Search facilities are limited
• Not possible to link requirements with proposed requirements changes
• No automated navigation from one requirement to another
Requirements Database
• Each requirement is represented as one or more database entities
• Database query language is used to access requirements
• Advantages
• Good query and navigation facilities
• Support for change and version management
• Disadvantages
• Readers may not have the software/skills to access the requirements
database
• The link between the database and the requirements document must be
maintained
Change Management
•Change management is concerned with the
procedures, processes and standards which are used
to manage changes to system requirements
•Change management process includes:
•Some requirements problem is identified.
•The proposed changes are analyzed
•The change is implemented.
Change Analysis and Costing
Change request rejection
• If the change request is invalid. This normally arises if a customer has misunderstood something about
the requirements and proposed a change which isn’t necessary.
• If the change request results in consequential changes which are unacceptable to the user.
• If the cost of implementing the change is too high or takes too long.
Change processing
Proposed changes are usually recorded on a change request form which
•
is then passed to all of the people involved in the analysis of the change
Change request forms (CRF) may include:
•
Fields for documenting the change analysis
•
data fields
•
responsibility fields
•
status field
•
Traceability
•Traceability information is information which helps
you assess the impact of requirements change.
•Types of traceability information:
• Backward-from traceability - Links requirements to their sources in other documents or
people
• Forward-from traceability Links requirements to the design and implementation
components
• Backward-to traceability Links design and implementation components backs to
requirements
• Forward-to traceability Links other documents (which may have preceded the
Types of traceability
• Requirements-sources traceability- Links the requirement and the people or documents
which specified the requirement
• Requirements-requirements traceability- Links requirements with other requirements
which are, in some way, dependent on them. This should be a two-way link (dependents
and is-dependent on)
• Requirements-architecture traceability- Links requirements with the sub-systems where
these requirements are implemented.
• Requirements-design traceability- Links requirements with specific hardware or software
components in the system which are used to implement the requirement
• Requirements-interface traceability - Links requirements with the interfaces of external
Table
• Traceability tables show the relationships between requirements or
between requirements and design components
• List
• Traceability tables become more of a problem when there are
hundreds or thousands of requirements as the tables become large
and sparsely populated.
•
• Traceability lists are simple lists of relationships which can be
implemented as text or as simple tables
Policies
• Traceability policies define what and how traceability information
should be maintained.
• It may include:
• What information should be maintained
• Which techniques/ matrix should be used
• Role of people e.g. traceability manager
• Handling policy exceptions
• Factors influencing traceability policy:
• No. of requirements
• Estimated system lifetime
• Level of Organizational maturity
• Project team size and composition
• Type of system
