Lecture 10
Fundamentals of Requirements
Management
Course
Topics
•Why Requirements Engineering?
•Introduction to Requirements
•How to Write Good Requirements
•RE in Software Development Life Cycles
•Requirements Discovery
•Fundamentals of Goals and Scenarios
•Agile Estimation and Features Prioritization
•Requirements Conflicts and Negotiation
•Requirements Validation
•Fundamentals of Requirements Management
3
Lecture Objectives
➢
Learn how to manage requirements artifacts
➢
Learn the fundamentals of requirements
traceability
Loading…
4
Requirements Engineering Activities
Requirements Engineering
Requirements
Inception
Elicitation
Requirements
Development
Analysis
Requirements
Management
Specification
Verification
Sources of change
Loading…
6
Requirements Change is Inevitable
o
o
➢
➢
➢
Better understanding of the domain: new requirements become
apparent
Everything else is changing (business, context, technologies,
markets…)
Changing customer priorities, new needs, new competitors
Technical or business opportunities (cloud, IoT, blockchains…)
Changing laws, regulations, polices, etc.
Requirements errors, conflicts, and inconsistencies
Technical, schedule, or cost problems
➢
➢
o
o
Change is as difficult to control as it is inevitable!
Possible responses to change
Ignore it…
Add, modify, or remove requirements
➢
➢
Introduction to Requirements
Management
8
Requirements Management
A systematic approach to eliciting, organizing, and
documenting the requirements 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
[1] Leffingwell & Widrig 1999, p.16
9
Requirements Management Activities
•
•
•
•
•
•
Requirements management includes all activities intended to
maintain the integrity and accuracy of expected requirements
Manage changes to agreed requirements
Keep project plans synchronized with requirements
Control versions of individual requirements and versions of
requirements documents
Manage relationships between requirements
Managing the dependencies between the requirements and
other documents/artifacts produced in the systems
engineering process
Track requirements status
10
Expectations of Requirements
Management
➢
Identification of individual requirements (Unique
Identification)
➢
•
•
•
Traceability from highest level requirements to implementation
Established via links through a requirements database
Links between requirements and design models, tests, code…
Coverage and consistency analysis
➢
•
Impact assessments of proposed changes
Which other requirements (and other linked artifacts) will be
affected by a change
11
Expectations of Requirements Management (2)
➢
o
o
➢
o
➢
Controlled access to current project information
A shared database ensures that all users are working with
current data (consistency, parallel access, unique source of
truth)
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
Loading…
Deployment of required tool support
All of this requires planning!
12
Identification of Requirements
➢
It is essential for requirements management that every requirement
has a unique identification
➢
o
Problem with a hierarchical approach (2.1, 3.2.4, ...):
Numbers (dynamically updated) cannot be assigned uniquely and
definitively if the document is restructured
➢
o
Problem with 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 security requirements). But… it is difficult to give
only one category to a requirement
➢
o
Conclusion: avoid encoding too much information in the ID!
A simple unique integer number suffices!
13
Requirements have Attributes
➢
➢
•
•
•
•
•
•
➢
➢
Attributes 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
14
Requirements Change Status
➢
•
Help manage the requirement lifecycle
Their number and nature depend on the process in place
➢
•
•
•
•
•
•
Examples 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
15
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
16
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
Check request
validity
Valid
request
Find directly
affected
requirements
Req. list
Find dependent
requirements
Requirements change list
Cost
Requirements
information
changes
Propose
Assess cost
Assess costs
requirements
acceptability
of change
changes
Customer
information
Rejected request
consequential changes may be
unacceptable to user/customer
Source of figure: Kotonya and Sommerville
Customer
information
negotiations with customers
risk is too high
Rejected request
Accepted
change
Rejected request
cost/time required for the implementation
of change is too high/long
17
Version Control
➢
•
•
Every version of a requirement needs to be uniquely
identified
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, etc.
Standard markers for revisions (e.g., strikethrough or
underlined text, coloring, line markers)
➢
•
•
Version control tools may be used
To store and manage the revision history
To store justifications (to add, modify, delete, reject a
requirement)
Traceability
19
Traceability Quotes (1)
➢
A link or relationship defined between entities 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
➢
One cannot manage what cannot be traced.2
[1] Gotel & Finkelstein, 1994; [2] IEEE Standard 830-1998
20
Traceability Quotes (2)
➢
Traceability gives essential assistance in understanding the
relationships that exist within and across software requirements,
design, and implementation.3
➢
Traceability information helps assess the impact of changes to
requirements, connecting these requirements as well as
requirements for other representations of the system.3
➢
Traceability is often mandated by contracts and standards, e.g.,
military and aerospace 1.
[1] Gotel & Finkelstein, 1994; [2] IEEE Standard 830-1998; [3] Palmer, 2000;
Typical Project Data
Change
Requests
Regulatory
Codes
System
Requirements
Design
Documentation
User
Requirements
Sub-System
Requirements
Sub-System
Requirements
Component
Requirements
Component
Requirements
Fault Logs
Stakeholders
Source Code in
packages, components,
and versions..
Project Plans
Queries
23
Traceability Difficulties
➢
Various stakeholders require different information
➢
Huge amount of requirements traceability information must be
tracked and maintained
➢
Integrating heterogeneous models/information from/to different
sources (requirements, design, tests, code, documentation,
rationales…) is not trivial
➢
Manual creation of links is very demanding (likely the most
annoying problem)
Specialized tools must be used
o
➢
Requires organizational commitment (with an understanding of the
potential benefits)
24
Backward and Forward Traceability
➢
•
•
Backward traceability
To previous stages of development
Links other documents (which may have preceded the
requirements document) to relevant requirements
➢
•
•
Forward traceability
Links requirements to the design and implementation components
Help assure that all requirements have been satisfied
Business plan
Forward-to traceability
Requ irements Document
Forward-from traceability
Design Specification
Backward-from traceability
Backward-to traceability
25
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
26
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, …
More amenable to automation than traceability table
Depends -on
R1
R1
R2
R3
R4
R5
R6
R2
*
R3
*
R4
*
*
R5
R6
*
*
*
*
27
Traceability matrix for a single relationship type (ex.
satisfies relationship)
28
Traceability matrix for several relationship types
29
Sample Traceability Matrix
Loading…
30
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
Requirement
R1
R2
R3
R4
R5
Depends-on
R3, R4
R5, R6
R4, R5
R2
R6
31
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
32
Simple Example of Traceability Link Types
User
requirements
Functional
requirements
Satisfies
Design
specifications
Satisfies
Tests
Tests
Tests
Standards
Acceptance tests
Functional tests
Unit tests
33
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 (typed attributes)
Structure of folders, modules, objects
Stereotypes, composition…
Link types (associations)
Satisfies, tests, refines, contains, contributes to, threatens,
justifies…
Link attributes (association classes)
Link cardinalities/multiplicities
…
34
Example – One Traceability Information Model
Traceability
Information
Model (TIM)
27
Tools to document traceability
Information
➢
➢
➢
General purpose tools (e.g., spreadsheet programs, word
processors, hypertext editors)
Suitable for small and short term projects
Not sufficient for extensive requirements tracing purposes
Requirements management tools
➢
Suitable for projects producing large and complex systems
➢
Require investments (e.g., licenses, training end-users,
system maintenance, consultation)
➢
Examples: Rational RequisitePro, DOORS
36
Visualization of Objects and Attributes (DOORS)
37
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 often be followed in either direction
Possible to have many links between the same two objects
Links also have types and possibly attributes!
38
DOORS – Creating and Accessing Links
39
Traceability and Impact Analysis (DOORS)
1.
User
Reqts
820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and development
activities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or result
in, input to the design and development process.
The plans shall be reviewed as design and development evolves.
The plans shall be updated as design and development evolves.
The plans shall be approved as design and development evolves.
2.
820.30(c) Design Input
2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the user
and patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the user
and patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.
2.4. The procedures shall include a mechanism for addressing ambiguous requirements.
2.5. The procedures shall include a mechanism for addressing conflicting requirements.
2.6. The design input requirements shall be documented by a designated individual(s).
2.7. The design input requirements shall be reviewed by a designated individual(s).
2.8. The design input requirements shall be approved by a designated individual(s).
2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.
2.10. Questions.
2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of
design input.
2.10.2. From what sources are design inputs sought?
2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)
2.10.3.1.
intended use
2.10.3.2.
user/patient/clinical
2.10.3.3.
performance characteristics
2.10.3.4.
safety
2.10.3.5.
limits and tolerances
2.10.3.6.
risk analysis
2.10.3.7.
toxicity and biocompatibility
2.10.3.8.
electromagnetic compatibility (EMC)
2.10.3.9.
compatibility with accessories/auxiliary devices
2.10.3.10. compatibility with the environment of intended use
2.10.3.11. human factors
2.10.3.12. physical/chemical characteristics
2.10.3.13. labeling/packaging
2.10.3.14. reliability
2.10.3.15. statutory and regulatory requirements
2.10.3.16. voluntary standards
2.10.3.17. manufacturing processes
2.10.3.18. sterility
2.10.3.19. MDRs/complaints/failures and other historical data
2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?
2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
Technical Reqts
Desig
n
1. 820.30(b) Design and Development Planning
Comply with FDA Design Control Guidance GMP Regulation
Comply with FDA Design Control Guidance GMP Regulation
1.1. and
Identify
impacted elements due to a change in another element
Each manufacturer shall establish and maintain plans that describe or reference the design
development
• Traceability Reports: consistency
activities and define responsibility for implementation.
with
driving
design
elements
1. Capture design and related information
1. Capture
design
and related
information
• Impact Reports: other design1.1.
1.1. Input electronically formatted data
Input electronically
elements
affected formatted data
The
plans
shall
identify
and
describe
the
interfaces
with
different
groups
or
activities
that
provide,
or
result
1.2. Reference external information sources
1.2. Reference external information sources
• Links to impacted design elements
in, input to the design and development process.
1.3. Reference external documentation
1.3. Reference external documentation
2.
3.
4.
5.
6.
1.1.1. Create backward traces to design elements within and across any organizational
procedure
2. Store design and related information
• Traceability Reports: Procedure
2.1. Identify
and tag design information as unique “design elements”
Attribute
2.2. Organize
design
elements
1.1.2. Create backward traces to design
elements
within
and across any project milestone
2.2.1. Organize by Design Control Guidance Element
2.2.1. Organize by Design Control Guidance Element
• Traceability Reports: Milestone
Attribute
2.
820.30(c)
Design
Input
2.2.2. Organize by inter-relationships
2.2.2. Organize by inter-relationships
2.1.
Each
manufacturer
shall
establish
procedures
to
ensure
that
the
design
requirements
relating
to
a
1.1.3.
Create
backward
traces
to
design
elements
within
and are
across
Design Control
2.3. Ensure all design elements are available
2.3. Ensure all design
elements
available
device
are
appropriate
and
address
the
intended
use
of
the
device,
including
the
needs
of
the
user
Guidance
Elements
2.3.1. Store design elements by Design Control Guidance Element
2.3.1. Store design elements by Design Control Guidance Element
andhistorical
patient. values
2.3.2. Store design elements and their
2.3.2.
Store elements
design elements and their historical values
• Traceability Reports: Linked
design
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a
1.1.4.ofCreate
elements within and across any organizational
device are appropriate and address the intended use of the device, including the needs
the userforward impacts3.to design
Manage all user needs
Manage all user needs
procedure
and patient.
3.1. Identify the source of the user need
3.1. Identify the source of the user need
2.3. The procedures shall include a mechanism for addressing incomplete requirements. • Impact Reports: Procedure
3.2. Identify all user types (groups)
3.2. Attribute
Identify all user types (groups)
2.4. The procedures shall include a mechanism for addressing ambiguous requirements.
3.3. Identify the customer (s)
3.3. Identify
the customer
1.1.5. Create forward impacts to design
elements
within (s)
and across any project milestone
2.5.
The
procedures
shall
include
a
mechanism
for
addressing
conflicting
requirements.
3.4. Profile the expected patients
3.4. Attribute
Profile the expected patients
• Impact Reports: Milestone
The(family)
design input requirements shall be documented by a designated individual(s).
3.5. State the intended use of the 2.6.
product
3.5. State the intended use of the product (family)
elements
within and
across
Design
Control
2.7.forThe
input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design
3.6. Capture the acceptance criteria
eachdesign
user need
3.6. Capture
the acceptance
criteria
for each
user need
2.8. The design input requirements shall be approved by a designated individual(s).
Guidance Elements
• Impact Reports: Linked
Manage design input requirements2.9. The approval, including the date and signature of the individual(s) approving the requirements,
4. Manage
input requirements
designdesign
elements
shall be documented.
4.1. Identify the source of the requirement
4.1. with
Identify
the source
of the requirement
1.2.
Associate
changed
design
elements
related
elements
2.10. Questions.
4.2. Identify the associated user need
4.2. Identify the associated user need
Linkof Change Design Object with
affected design element(s)
Summarize the manufacturer's written procedure(s) for identification and• control
4.3. Capture requirement description 2.10.1.
and attributes
4.3. Capture requirement description and attributes
• Traceability Links and Reports
design input.
affected
design
element(s)
4.4. Capture acceptance criteria
4.4.from
Capture
acceptance
criteria
2.10.2. From what sources are design inputs sought?
• Impact Links and Reports from
4.5. Assign responsibility for each requirement
4.5. affected
Assign responsibility
for each requirement
design element(s)
2.10.3.
Do
design
input
procedures
cover
the
relevant
aspects,
such
as:
(Mark
all
that
apply
and
4.6. Manage incomplete requirements
4.6. Manage
1.2.1. Associate design element changes
withincomplete
decisions,requirements
rationale, and approval authority
list
additional
aspects.)
4.7. Manage ambiguous requirements
4.7. Manage ambiguous requirements
information
2.10.3.1.
intended use
4.8. Manage conflicting requirements
4.8. Manage conflicting requirements
• Change Decision Objects4.9.
2.10.3.2.
user/patient/clinical
with
following
Attributes:
4.9. Approve all requirements
Approve
all requirements
2.10.3.3.
performance characteristics
• Disposition Attribute
2.10.3.4.
safety
Manage acceptance
• Decision Attribute 5. Manage acceptance
2.10.3.5.
limits and tolerances
5.1. Ensure the acceptance of every user need
5.1. Ensure the acceptance of every user need
•
Rationale
Attribute
risk analysis
5.2. Ensure the acceptance of every design2.10.3.6.
input requirement
5.2. Ensure the acceptance of every design input requirement
2.10.3.7.
• Owner Attribute
5.3. Document the results of every user need
acceptancetoxicity
test and biocompatibility
5.3. Document the results of every user need acceptance test
electromagnetic
compatibility (EMC)
• Management Approval Attribute
5.4. Document the results of every design 2.10.3.8.
input requirements
test
5.4. Document the results of every design input requirements test
compatibility with accessories/auxiliary devices
5.5. Make acceptance results available 2.10.3.9.
acceptance
results availableprocedure
1.2.2. Provide associations within5.5.
andMake
across
any organizational
2.10.3.10. compatibility with the environment of intended use
• Change Design Object Traceability Link on Procedure Attribute
2.10.3.11. human factors
Manage change
6. Manage change
2.10.3.12. physical/chemical characteristics
• Change Design Object Impacts
Link on
Procedure
6.1. Maintain history of design element changes
6.1. Maintain
history
of designAttribute
element changes
2.10.3.13. labeling/packaging
6.1.1. Make complete change history available
Makeany
complete
change
history available
1.2.3. Provide associations within and6.1.1.
across
project
milestone
2.10.3.14.
reliabilityprocedure
6.1.2. Maintain history within and across
any organizational
6.1.2. Maintain
history
within and
across any organizational procedure
• Change Design Object Traceability
Link on
Milestone
Attribute
2.10.3.15.
statutory
and regulatory requirements
6.1.3. Maintain history within and across
any project
milestone
6.1.3. Maintain history within and across any project milestone
• Change Design Object Impacts
Link
on
Milestone
Attribute
2.10.3.16.
voluntary
standards
6.1.4. Maintain history within and across any Design Control Guidance Elements
6.1.4. Maintain history within and across any Design Control Guidance Elements
2.10.3.17.
manufacturing
processes
1.2.4.
Provide
associations
within
and
across
Design
Control
Guidance
6.2. Capture frequency and nature of element changes
6.2. Capture frequency and nature of element Elements
changes
2.10.3.18.
sterility
•
6.2.1. Provide rationale for change
6.2.1. Provide
fordesign
change elements
Change Design Object Traceability
Linkrationale
to traced
2.10.3.19. MDRs/complaints/failures and other historical data
6.2.2. Describe decisions made
6.2.2.
Describe
decisions
madeelements
• Change Design Object Impacts
Link
to linked
design
2.10.3.20.
6.2.3. Identify approval authority for the
change design history files (DHFs)
6.2.3. Identify approval authority for the change
1.3. identified?
Mange the change process
2.10.4.of approving
For the specific
design covered, how were the design input requirements
6.2.4. Capture date, time, and signature
authority
6.2.4. Capture date, time, and signature of approving authority
For
specific
design covered, how were the design input requirements•reviewed
for Change Module
Design
6.3. Identify impacted elements due to2.10.5.
a change
inthe
another
element
6.3. Identify impacted elements due to a change in another element
adequacy?within and across any organizational procedure
• Design Change Reports
6.3.1. Create backward traces to design elements
6.3.1. Create backward traces to design elements within and across any organizational procedure
6.3.2. Create backward traces to design elements within and across any project milestone
6.3.2. Create backward traces to design elements within and across any project milestone
• Object History
• Object History Reports
• Versions
• Baselines
The plans shall be reviewed as design and development evolves.
Store design and related information
The plans shall
be updated
as design
and development evolves.
2.1. Identify and tag design information
as unique
“design
elements”
The plans shall be approved as design and development evolves.
2.2. Organize design elements
Test Cases
1.1. Identify impacted elements due to a change in another element
• Traceability Reports: consistency with driving design elements
• Impact Reports: other design elements affected
• Links to impacted design elements
1.1.1. Create backward traces to design elements within and across any organizational
procedure
• Traceability Reports: Procedure Attribute
1.1.2. Create backward traces to design elements within and across any project milestone
• Traceability Reports: Milestone Attribute
1.1.3. Create backward traces to design elements within and across Design Control
Guidance Elements
• Traceability Reports: Linked design elements
1.1.4. Create forward impacts to design elements within and across any organizational
procedure
• Impact Reports: Procedure Attribute
1.1.5. Create forward impacts to design elements within and across any project milestone
• Impact Reports: Milestone Attribute
1.1.6. Create forward impacts to design elements within and across Design Control
Guidance Elements
• Impact Reports: Linked design elements
1.2. Associate changed design elements with related elements
• Link Change Design Object with affected design element(s)
• Traceability Links and Reports from affected design element(s)
• Impact Links and Reports from affected design element(s)
1.2.1. Associate design element changes with decisions, rationale, and approval authority
information
• Change Decision Objects with following Attributes:
• Disposition Attribute
• Decision Attribute
• Rationale Attribute
• Owner Attribute
• Management Approval Attribute
1.2.2. Provide associations within and across any organizational procedure
• Change Design Object Traceability Link on Procedure Attribute
• Change Design Object Impacts Link on Procedure Attribute
1.2.3. Provide associations within and across any project milestone
• Change Design Object Traceability Link on Milestone Attribute
• Change Design Object Impacts Link on Milestone Attribute
1.2.4. Provide associations within and across Design Control Guidance Elements
• Change Design Object Traceability Link to traced design elements
• Change Design Object Impacts Link to linked design elements
1.3. Mange the change process
• Design Change Module
• Design Change Reports
• Object History
• Object History Reports
• Versions
• Baselines
•
•
•
40
What are Suspect Links?
If documents are linked …
… a change by this
user here…
… shows up as a
warning flag to this
user here.
Proactively know when changes affect your requirements
Suspect link indicates that an element may have been
affected by a change
Help ensure that ripple effects of changes are considered