In this Slide:
__________________________________________________________
SRE – Requirements
Management
BSEF15
(V)
Abdul
Razaq Ali
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 dependencies between system requirements.
Stable and Volatile Requirements
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.
Symbolic identification
Requirements can be identified by giving them a symbolic
name which is associated with the requirement itself. For example, EFF-1,
EFF-2, EFF-3 may be used for requirements which relate to system efficiency
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
comments 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 requirements document) to relevant
requirements.
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 systems which are used in the provision of the
requirements
Traceability Table
Traceability
tables show the relationships between requirements or between requirements and
design components
Traceability 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
Traceability 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
Questions ?
No comments :
Post a Comment