Software
Requirements Engineering
Lecture 26
Requirements Management
SESD-2213
FALL 2020
Dr. Anam Mustaqeem
[email protected]Office: Cabin #2, F303 Building A
OFFICE HOURS: Monday : 10:00 AM- 02:00 PM
Thursday: 10:00 AM- 02:00 PM
3 Table of Contents
Traceability
Baselines
Change Management
Requirements Management Tools
[1] Suzanne & James Robertson, “Requirements-Led Project Management”, Addison-Wesley, 2004
4 Types of Traceability (1)
Requirements – source traceability
Links requirements with a person or document
Requirements – rationale traceability
Requirements – requirements traceability
Links requirements with other requirements which are, in some way, dependent on them
Requirements – architecture traceability
Links requirements with the subsystems where these requirements are implemented (particularly important
where subsystems are being developed by different subcontractors)
Requirements – design traceability
Links requirements with specific hardware or software components in the system which are used to implement
the requirement
5 Types of Traceability (2)
Requirements – interface traceability
Links requirements with the interfaces of external systems which are used in the provision of the requirements
Requirements – feature traceability
Requirements – tests traceability
Links requirements with test cases verifying them (used to verify that the requirement is implemented)
Requirements – code traceability
Generally not directly established, but can be inferred
6 Representation – Traceability Table
Show the relationships between requirements or between requirements and other artifacts
Table can be set up to show links between several different elements
Backward and forward traceability
Difficult to capture different types of links
7 Representation – Traceability Matrix
Define links between pairs of elements
E.g., requirements to requirement, use case to requirement, requirement to test case…
Can be used to defined relationships between pairs
E.g., specifies/is specified by, depends on, is parent of, constrains…
More amenable to automation than traceability table
8 Representation – Traceability List
Traceability matrices become more of a problem when there are hundreds or thousands of requirements
as the matrices become large and are sparsely populated
A simplified form of a traceability matrix may be used where, along with each requirement description,
one or more lists of the identifiers of related requirements are maintained
9 Example – DOORS Links
A relationship between two objects in the DOORS database is established using a link
One source object and one destination object
Links can be followed in either direction
Possible to have many links between the same two objects
Links also have types and attributes!
10 DOORS – Link Matrix View
11 DOORS – Hierarchical Link View
12 DOORS – Types of Analysis
Impact Analysis
Analyze out-links (which objects in other modules are affected when this module is changed)
Traceability Analysis
Analyze in-links (changes in these objects will affect this module)
May involve multiple levels of objects/documents
13 What are SuspectIfLinks?
documents are linked …
… a change by … shows up as a
this user here… warning flag to
this user here.
Proactively know when changes effect your requirements
Suspect link indicates that element may have been affected by a change
Help ensure ripple effects of changes are considered
14 Suspect Links
Visible as indicators or with change notes (added/deleted)
15 Traceability Planning
Planning traceability? Yes, just like any other project!
Who are the stakeholders?
What are the needs (analysis, reports…)?
Useful, measurable, feasible objectives
Definition of links and attributes
Can some be inferred automatically?
Process (who collects and when to collect traceability information)
Roles, access
Data/link input and updates
Exceptional situations (e.g., lack of time)
Representations, queries, tools
…
Traceability policies define what and how traceability information should be maintained
16 Factors to Consider during Planning (1)
Number of requirements
The greater the number of requirements, the more the need for formal traceability policies
Expected system lifetime
More comprehensive traceability policies should be defined for systems which have a long lifetime
Maturity level of organization
Detailed traceability policies are more likely to be implemented and used properly in a cost-effective way in
organizations which have a higher level of process maturity
Size of project and team
The larger the project or team, the greater the need for formal traceability policies
17 Factors to Consider during Planning (2)
Type of system
Critical systems such as hard real-time control systems or safety-critical systems need more comprehensive
traceability policies than non-critical systems
Additional constraints from customer
E.g., compliance to military standard
Traceability links should be defined by whoever has the appropriate information available
18 Modeling Traceability
The types of links to use (and their attributes) must be defined for different types of requirements
It is a design problem!
May be modeled with a UML class diagram (metamodel)
Object types (classes)
Object attributes (attributes)
Structure of folders, modules, objects
Stereotypes, composition…
Link types (associations)
Satisfies, tests, refines, contains, contributes to, threatens, justifies…
Link attributes (association classes)
…
19 Types of Traceability Links
Note the types of links in the previous examples, as well as the types of objects they relate
Satisfies, Tests
Refines, References, Contains...
Others could be created
Contributes, Contradicts, Justifies, Depends on...
20 Other Example of Traceability Links
21 Cardinality of Traceability Links
Depending on the traceability information, the cardinality of traceability links may be
One-to-one
E.g., one design element to one code module
One-to-many
E.g., one functional requirement verified by multiple test cases
Many-to-many
E.g., a use case may lead to multiple functional requirement, and a functional requirement may be common to several use
cases
Baselines
23 Baseline
Non-modifiable (read-only) version of a document
Describes a moment in time
May include multiple documents at the same time
Enables document comparison and management
Comes with a change history for the document
Information on objects, attributes, and links created, deleted, or edited since the creation of the baseline
Often also contains information on user sessions (when the document was opened, by whom…)
Requires access control
It is advisable to establish a baseline for a new document that is imported into the document
management system
In order not to lose any changes
24 Baseline for Requirements
Represents the set of functional and non-functional requirements that the development team has
committed to implement in a specific release
Before going into the baseline, the requirements should be reviewed and approved by stakeholders
Once in the baseline, all changes should follow a defined change control process
Baseline
Different viewpoints Shared understanding
No formal documents Configuration management
Always changing Change management
25 Baseline Usage
Baselines may be
Created
Complete image of requirements state at a given time
Deleted
Visualized
Possibility to go back
Compared
To see changes since a certain time
Copied
Signed
For authorization, contract
DOORS – Baseline Compare
26
Change Management
28 Change Management (1)
The more things change…
If you see change not as
an enemy, but as a
welcome friend, you will
secure the most valuable
prize of all – the future…
29 Change Management (2)
Concerned with the procedures, processes, and standards which are used to manage changes to a system
requirements
Change management policies may cover
The change request process and the information required to process each change request
The process used to analyse the impact and costs of change and the associated traceability information
The membership of the body that formally considers change requests
Software support (if any) for the change control process
A change request may have a status as well as requirements
E.g., proposed, rejected, accepted, included...
30 Change Management Process
Some requirements problem is identified
Could come from an analysis of the requirements, new customer needs, or operational problems with the system
The requirements are analysed using problem information and requirements changes are proposed
The proposed changes are analysed
How many requirements (and, if necessary, system components) are affected? Roughly how much would cost,
in both time and money?
The change is implemented
A set of amendments to the requirements document or a new document version is produced (of course this
should be validated with whatever normal quality checking procedures are in place)
31 Change Request Form
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 may include
Date, Customer, Requester, Product including version
Description of change request including rationale
Fields to document the change analysis
Signature fields
Status
Comments
32
Change Analysis and Costing – Example
customers may misunderstand requirements and
their context and suggest unnecessary changes
with the help of traceability information
risk is too high
negotiations with customers
consequential changes may be
unacceptable to user/customer cost/time required for the implementation
of change is too high/long
Source of figure: Kotonya and Sommerville
33 Different Management Aspects
Change Management
How does a customer submit change requests?
How is this request being monitored, prioritized, and implemented?
Configuration Management
Versioning, labelling, and tracking code and other components during the development cycle of software
Release Management
Defines how and when different hardware and software will be made available together as a product
34 Tool Support for Change Management
May be provided through requirements management tools or through configuration management tools
Tool facilities may include
Electronic change request forms which are filled in by different participants in the process
A database to store and manage requests
A change model which may be instantiated so that people responsible for one stage of the process know who is
responsible for the next process activity
Electronic transfer of forms between people with different responsibilities and electronic mail notification when
activities have been completed
Electronic signatures
Discussion forums
In some cases, direct links to a requirements database
Requirements Management Tools
36 What Kind of Tool Do We Need?
Different companies will use different tools, which may or may not be tailored to the requirements management
task
Word processor (Microsoft Word with templates…)
Spreadsheet (Microsoft Excel…)
Industrial-strength, commercial RM tools
IBM/Telelogic DOORS, IBM Requisite Pro, Borland CaliberRM…
Internal tools
GenSpec (Hydro-Quebec)…
Open source RM tools
OSRMT: http://sourceforge.net/projects/osrmt
Bug tracking tools (free or not)
Bugzilla…
Collaboration tools (free or not)
TWiki…
37 What Should We Look For in a Tool?
Types/attributes for requirements and links Requirements document generation
Specifications and models Monitoring of requirements statuses
Version and change management Access control
Database repository Import/export
Traceability Communication with stakeholders
Analysis (impact, completeness, style, Scripting language (for automation)
differences…) Reuse of requirements, models, projects
Automatic inspection of requirements …
(according to rules)
Visualization and reports
38 RM Tool Architecture – Example
39 Requirements Management Implies Integration!
40 Approaches – Document or Database? (1)
Requirements have to be stored in such a way that they can be accessed easily and related to other
requirements
Document (e.g., Word)
Easy to use, easy to access, simple training
Requirements are all stored in the requirements document
It is easy to produce the final requirements document
But: Traceability? Status reports? Granularity of requirements? Search and navigation facilities? Change
management? Version control? Analysis? Simultaneous access control?...
41 Approaches – Document or Database? (2)
Database
Good for management, controlled access, links, analysis, reports
Good query and navigation facilities
Support for change and version management
But: hard (and costly) to configure, manage, and use; link between the database and the requirements document
must be maintained (final requirements document must be generated)
Ideally: Target the benefits of both
E.g., DOORS and RequisitePro offer integrations with Word (import/export) as well as document-oriented
views (for the “look and feel”…)
42 How About Evolving the Process Itself?
Evolution of requirements types
Adding / modifying / deleting
Attributes
Link types
Requirements status
…
Evolution of change management
Adding / modifying / deleting
Attributes
Lifecycle status
Forms
…
43 TWiki Overview
A generic Wiki tool (TWiki.org)
Promotes collaboration
Database-driven
Access and version control
Forms and queries
State-based workflows (processes)
Text and graphics
Lightweight, extensible (plug-in architecture)
Example of Forms and Queries
Requirements: http://cserg0.site.uottawa.ca/twiki/bin/view/ProjetSEG/UCMNavRequirements
Library: http://cserg0.site.uottawa.ca/twiki/bin/view/UCM/UCMVirtualLibrary
Use Cases: http://cserg0.site.uottawa.ca/seg/bin/view/CSI4900/UseCases
44 TWiki for Requirements Management
45 Twiki – Requirement Example
46 TWiki – Requirement Form Example
47 Using TWiki…
We have:
Requirement types description with configurable statuses & attributes
Bidirectional links (WikiWords)
Configurable requests, filtering, reports
Access control and version management (showing differences)
Change management (again with forms, process, etc.)
Discussions, attachment of documents/images
Export (HTML)
Scripting language (Perl)
But do we really have:
Graphical view of traceability?
Editable tables (à la Excel/Word)?
Baselines? Tool integration? Imports? Analysis?
48 IBM Requisite Pro
Keep your team on track
Microsoft Word
Database
3 interfaces - work the way you
want Web
Document centric or database
centric - your choice
49 IBM Requisite Pro – Types, Attributes, and Views
User defined requirement
types
User defined attributes
User defined filters (views)
Saved views
50 IBM Requisite Pro – Traceability
51 IBM Requisite Pro – Change Management
52 IBM Requisite Pro – Integration
IBM Rational TestManager IBM Rational XDE and IBM Rational
Testers view current state Rose, Rational Software Architect and
of requirements from their tool Rational Software Modeler
Developers view current state of
requirements from their tool
