Requirements Management: Based On Material From
Requirements Management: Based On Material From
Requirements Management: Based On Material From
Requirements Management
3
Some Problems Due to Changing Requirements
• Requirements changing towards the end of development
without any impact assessment
4
Requirements Management
A systematic approach to eliciting, organizing, and
documenting the requirement of the system, and a process
that establishes and maintains agreement between the
customer and the project team on the changing requirements
of the system.1
6
Requirements Management Activities (2)
Requirements
Management
9
Requirements Change Factors (1)
• Requirements errors, conflicts, and inconsistencies
• May be detected at any phase (when requirements are analyzed,
specified, validated, or implemented)
• Evolving customer/user knowledge of the system
• When the requirements are developed, customers/users
simultaneously develop a better understanding of what they really
need
• Technical, schedule, or cost problems
• Difficult to plan and know everything in advance
• We may have to revisit the list of requirements and adapt it to the
current situation
10
Requirements Change Factors (2)
Changing customer priorities, new needs
• May be caused by a change in the system environment
(technological, business, political...), i.e., the context
• Business and strategic goals may change
• May be caused by the arrival of a new competitor
• Laws and regulations may change
• Collaborating systems may change
• May also be caused by technology changes in the enterprise
(migration to a new operating system, DBMS…)
• May be caused by organizational changes (organizational
structure, business processes, employees…)
11
Requirements Volatility
Requirements continuously change
• While the requirements are being elicited, analyzed, specified, and
validated and after the system has gone into service
Some requirements are usually more subject to change
than others
• Stable requirements are concerned with the essence of a system and its
application domain
• Derived from the client’s principal business activities or the domain model
• They change more slowly than volatile requirements
• E.g., a hospital will always have doctors, nurses, patients…
• Volatile requirements are specific to the instantiation of the system in a
particular environment for a particular customer at a particular time
• E.g., in a hospital, we can think of requirements related to the policies of the
government health system
12
Types 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
• Once the system is in place, some of these assumptions will be wrong
• Compatibility requirements
• These are requirements which depend on other equipment,
technology, or processes
13
Expectations of Requirements Management (1)
• Identification of individual requirements
14
Expectations of Requirements Management (2)
• Controlled access to current project information
• A shared database ensures that all users are working with current data
(consistency, parallel access)
• A central repository allows all users to see the information that they
need to see (visibility)
• Change control
• Change proposal system implements controlled process for managing
change
• How do we collect, document, and address changes?
15
Identification of Requirements
• It is essential for requirements management that every
requirement has a unique identification
• The most common approach is requirements numbering based on
chapter/section in the requirements document
• There are several problems with this approach
• Numbers cannot be unambiguously assigned until the document is
complete
• Assigning chapter/section numbers is an implicit classification of the
requirements may mislead readers of the document into thinking
that the most important relationships are with requirements in the
same section
16
Requirements Identification Techniques
• Dynamic renumbering
• Some word processing systems allow for automatic renumbering of
paragraphs and the inclusion of cross references
• As you reorganise your document and add new requirements, the
system keeps track of the cross references and automatically
renumbers your requirements 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 which is then
used for all subsequent references to the requirement
• Symbolic identification
• Requirements can be identified by giving them a symbolic name which
is associated with the requirement itself (e.g., SEC1, SEC2, SEC3…
may be used for requirements which relate to system security)
17
Requirements Have Attributes!
• Apart from an identifier, requirements should have attributes
that establish context and background, and go beyond the
requirement description
• For filtering, analysis, metrics…
• Creation date, Last update, Author, Stakeholders (Owners / Source)
• Version number
• Status, Priority, Importance, Stability
• Rationale, Comments
• Acceptance criteria
• Subsystem / Product release number
• …
• The more complex the project, the richer the attributes…
• Many attributes are predefined in RM tools, others are
defined by requirements engineers as required by the project
18
Requirements Attributes
• Classes and attributes of a requirements management
database
19
Requirements Status
• Help manage the requirement lifecycle
• Their number and nature depend on the process in place
• Example of a set of statuses:
• Proposed: by some stakeholder
• Approved: part of baseline, committed to implement
• Rejected: after evaluation
• Implemented: designed and implemented
• Verified: Relevant tests have passed
• Deleted: Removed from list
• RM includes amongst its tasks the tracking of the status of all
requirements during the project
20
Version Control
• Another essential aspect of requirements management
• Every version of a requirement needs to be uniquely identified
• The last version of a requirement must be available to all team
members
• Changes need to be documented and clearly communicated
• A version identifier must be updated with every change to the
requirement
• Requirements documents should include
• A revision history: changes, dates, by whom, why...
• Standard markers for revisions (e.g., strikethrough or underlined text,
coloring, line markers…)
• Version control tool may be used
• To store and manage the revision history
• To store justifications (to add, modify, delete, reject a requirement)
21
Traceability
Traceability Quotes (1)
• Requirements traceability refers to the ability to describe and follow the
life of a requirement, in both forwards and backwards direction (i.e., from
its origins, through its development and specification, to its subsequent
deployment and use, and through all periods of ongoing refinement and
iteration in any of these phases)”.1
[1] Gotel & Finkelstein, 1994; [2] IEEE Standard 830-1998; [3] Palmer, 2000; [4] Watkins and Neal, 1994
23
Traceability Quotes (2)
• Traceability is often mandated by contracts and standards.1
• E.g., military and aerospace
[1-2] Watkins and Neal, 1994; [3] Kotonya and Sommerville, 1998; [4] Greenspan, McGowan, 1978
24
Importance of Traceability (1)
Requirements cannot be managed effectively without
requirements traceability
A requirement is traceable if you can discover who suggested the
requirement, why the requirement exists, what requirements are related
to it, and how that requirement relates to other information such as
systems designs, implementations and user documentation
25
Importance of Traceability (2)
Benefits of traceability
• Prevents losing knowledge
• Supports the verification process (certification, localization of defects)
• Impact analysis
• Change control
• Process monitoring (e.g., missing links indicate completion level)
• Improved software quality (make changes correctly and completely)
• Reengineering (define traceability links is a way to record reverse
engineering knowledge)
• Reuse (by identifying what goes with a requirement: design, code…)
• Risk reduction (e.g., if a team member with key knowledge leaves)
26
Traceability Difficulties
• Various stakeholders require different information
• Huge amount of requirements traceability information must
be tracked and maintained
• Manual creation of links is very demanding
• Likely the most annoying problem
• Specialized tools must be used
• Integrating heterogeneous models/information from/to
different sources (requirements, design, tests, code,
documentation, rationales…) is not trivial
27
Backward and Forward Traceability (1)
• Backward traceability
• To previous stages of development
• Depends upon each element explicitly referencing its source in earlier
documents
• Forward traceability
• To all documents spawned by a document
• Depends upon each element in the document having a unique name
or reference number
29
Backward and Forward Traceability (3)
Bottom to top from requirements’ point of view
• Backward-to traceability
• Links design and implementation components back to requirements
• Help determine why each item is designed/implemented
• Backward-from traceability
• Links requirements to their sources in other documents or people
• Help validation
• Help evaluate how changes to requirements impact stakeholders
needs
30
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
31
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
32
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
33
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
Depends -on
R1 R2 R3 R4 R5 R6
R1 * *
R2 * *
R3 * *
R4 *
R5 *
R6
34
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
35
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
36
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
37
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
38
Modeling Traceability
The types of links to use (and their attributes) must be
defined for different types of requirements
• It is a design problem!
40
Other Example of Traceability Links
Business
requirement
modifies
Drives specification of
Is origin of Is origin of
modifies modifies
Software functional
Depends on another
requirement
Is satisfied by
Is verified by Lead to creation of
Architectrue, Project plan
user interface, or System test
task
functional design
Is verified by Is implemented in
Is verified by
Unit test
41
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
42
Baselines
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
Baseline
45
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
46
Change Management
Change Management
• 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
48
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)
Identified
problem
Problem analysis and Change analysis Change
change specification and costing implementation
Revised
requirements
49
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
50
Change Analysis and Costing – Example
customers may misunderstand requirements and
their context and suggest unnecessary changes
with the help of traceability information
Rejected request
Change
request Req. list risk is too high
Check request Find directly Find dependent
validity affected requirements
Valid requirements
request
Requirements change list Rejected request
Cost
Requirements information Accepted
Propose changes change
Assess costs Assess cost
requirements of change acceptability
changes
52
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
53
Requirements Management Tools
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…
55
What Should We Look For in a Tool?
• Types/attributes for requirements • Requirements document
and links generation
• Specifications and models • Monitoring of requirements
• Version and change statuses
management • Access control
• Database repository • Import/export
• Traceability • Communication with stakeholders
• Analysis (impact, completeness, • Scripting language (for
style, differences…) automation)
• Automatic inspection of • Reuse of requirements, models,
requirements (according to rules) projects
• Visualization and reports •…
56
RM Tool Architecture – Example
57
Requirements Management Implies Integration!
Project-tracking
tool
Test
Version control
management
tool
tool
Requirements
management
tool
Change- Design
request tool modeling tool
Project
estimation tool
58
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
59
Approaches – Document or Database? (2)
• Database (e.g., DOORS)
• 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”…)
60
How About Evolving the Process Itself?
• Evolution of requirements types
• Adding / modifying / deleting
• Attributes
• Link types
• Requirements status
• …
61
Thinking About Getting a RM Tool?
• The list of potential criteria and the list of products can be
rather long…
• See the INCOSE study:
http://www.incose.org/ProductsPubs/Products/rmsurvey.aspx
• About 25 tools and 80 criteria, with explanations
62
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
63
TWiki for Requirements Management
64
Twiki – Requirement Example
65
TWiki – Requirement Form Example
66
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?
67
IBM Requisite Pro
Microsoft Word
Database
68
IBM Requisite Pro – Types, Attributes, and Views
69
IBM Requisite Pro – Traceability
70
IBM Requisite Pro – Change Management
71
IBM Requisite Pro – Integration
72