Effective Requirements Management –
an overview
Kristian Persson
Field Product Manager, Telelogic Asia/Pacific
Agenda
• What is Requirements Management?
• Why Requirements Management?
• Key concepts
– Quality and Requirements
– Systems
– Problem and Solution domain
– Information traceability
– Requirements and Modeling
– Requirements Driven Development
2
© Telelogic AB
Requirements are Vital
• Requirements are a clear statement of objectives.
• Requirements state the initial problem and the need that is to
•
•
be satisfied
Requirements define the characteristics of the set of
acceptable solutions
Requirements also provide guidance
in the selection of the most
appropriate solution
• Therefore, requirements provide
the map and compass
3
© Telelogic AB
Requirements Management
• NOT just a front-end activity
• Forms the back-bone of the WHOLE lifecycle
– Cradle-to-grave, not just development activity
• Helps you focus on the most important objectives
– Not all requirements are equal in cost, risk, benefit
• Saves money through EARLY defect identification
– “Quality is free” (Philip Crosby)
• The more complex the system, the greater the need
for
requirements to be well managed
(RMB-43)
4
© Telelogic AB
Requirements Management: Project Success
Reliable
Formal
Estimates
methodology
Standard
5% 5%
infrastructure
6%
Executive
support
Minimized scope
Clear business
objectives
12%
14%
15%
14%
17%
5%
7%
User
involvement
Experienced
Project Manager
Skilled Staff
Agile requirements process
Source: “Chaos Chronicles, III, 2003”. www.standishgroup.com
5
© Telelogic AB
The Benefits of Requirements Management
• Satisfaction: real stakeholder needs met
• Integration: the pieces work together
• Testability: know what to test the product against
• Communication: developers have consistent ideas of what
•
•
•
•
6
the product is for
Visibility: managers can take a global view
Change control: the impact of change can be assessed
Quality: we know what quality means for the stakeholder
Optimization: we build only what is wanted
© Telelogic AB
Quality and Requirements
• Quality: conformance to requirements
• Requirements management: delivering quality
throughout the life-cycle
7
© Telelogic AB
What is a system?
• A collection of components (people or machine)
– which co-operate in an organized way
– to achieve some desired result.
• A system is more than the sum of its parts
– it has emergent properties
• A system is always part of an enclosing system
– systems of systems
8
© Telelogic AB
Simple System: a Cup
Component: handle
Component: bowl
Interface: to hand
Interface: to mouth
Interface: to table
9
© Telelogic AB
Environment : gravity
Enclosing system
10
© Telelogic AB
Emergent Properties
• Properties not located in any particular component of a system,
e.g.
– Ability to float, or to fly
• Properties that depend on the way components interact, e.g.
– Journey time from London to Glasgow
– Reliability
• What about:
– Weight?
• Question: what are the emergent properties of the cup?
11
© Telelogic AB
Problem and Solution
Stakeholder
Requirements
Problem
definition
Risk of defining
the wrong
problem
Changing
design may
not mean
changing
requirements
System
Requirements
Abstract
solution
Risk of
unnecessarily
constraining
the solution
Design
Specific
solution
Risk of not meeting
the requirements
12
© Telelogic AB
Differentiating Problem and Solution
Problem
Stakeholder requirements
•
•
•
•
•
A description of the problem
and its context
Results that stakeholders want
from the system
Do not define the solution, other
than for environment
Quality of results
Owned by stakeholders or their
representatives (e.g. marketing)
“The user shall be able to ....”
13
Solution
System requirements
•
•
An abstract representation of
the solution
What the system does
•
Do not define the design
•
•
How well it does it
Owned by systems engineers
“The system shall do ….”
© Telelogic AB
Results of mixing Problem and Solution
• Don’t understand the problem
• Can’t decide on functions
• Developers dominate
• Can’t do acceptance
• User and system constraints muddled
• Unclear ownership
14
© Telelogic AB
The V-Model
Operational use
Statement of need
validating the product
Stakeholder
Requirements
Acceptance
test
satisfies
verifying the system
System
test
System
Requirements
satisfies
qualifying the subsystems
Subsystem
test
Subsystem
Requirements
satisfies
qualifying components
Component
Requirements
15
Component
test
© Telelogic AB
Requirements at every level
Operational use
Statement of need
validating the product
Stakeholder
Requirements
Acceptance
test
satisfies
verifying the system
System
test
System
Requirements
satisfies
qualifying the subsystems
Subsystem
test
Subsystem
Requirements
satisfies
qualifying components
Component
Requirements
16
Component
test
© Telelogic AB
Definition of Traceability
INFORMATION TRACEABILITY:
Understanding how information at a high-level is transformed
into low-level.
Understanding how needs are satisfied and qualified
Principle underpinning:
• Programme management
• Accountability
• Audit trails
• Risk management
• Safety management
17
© Telelogic AB
Traceability allows analysis
• impact
• impact coverage
• derivation
• derivation coverage
• completeness
• relevance
18
© Telelogic AB
Impact Analysis
Operational use
Statement of need
validates
Stakeholder
Requirements
Acceptance
test
satisfies
System
Requirements
validates
System
test
satisfies
Subsystem
Requirements
validates
Subsystem
test
satisfies
Component
Requirements
19
validates
Component
test
© Telelogic AB
Coverage Analysis
Operational use
Statement of need
validates
Stakeholder
Requirements
Acceptance
test
satisfies
System
Requirements
validates
System
test
satisfies
Subsystem
Requirements
validates
Subsystem
test
satisfies
Component
Requirements
20
validates
Component
test
© Telelogic AB
Life of a requirement statement
• Drafted
• Proposed
• Approved
– By customer
– By supplier
– By validation and test team
• Traced
• Reviewed
Y
•Impacted?
– Accepted
– Rejected
• Baselined
21
© Telelogic AB
Traceability view
User Reqts
1. 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.
Technical Reqts
Design
1. 820.30(b) Design and Development Planning
Comply with FDA Design Control Guidance GMP Regulation
Comply with FDA Design Control Guidance GMP Regulation
Each manufacturer shall establish and maintain plans that describe or reference the design
and development
1.1. Identify
impacted elements due to a change in another element
activities and define responsibility for implementation.
1. Capture design and related information
1. Capturewith
design
and related
information
driving
design
elements
 Traceability Reports: consistency
1.1. Input electronically formatted data
1.1.
Input electronically
Impact
Reports:
other
design
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
1.1.1.Create backward traces to design elements within and across any organizational
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?
The plans shall be reviewed as design and development evolves.
2. Store design and related information
2. Store design and related information
procedure
The plans shall
be updated
as design
and development evolves.
2.1. Identify and tag design information
as unique
“design
elements”
2.1. Identify
and tag design information as unique “design elements”
Attribute
 Traceability Reports: Procedure
The plans shall be approved as design and development evolves.
2.2. Organize design elements
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
2. 820.30(c) Design Input
Attribute
 Traceability Reports: Milestone
2.2.2. Organize by inter-relationships
2.2.2. Organize
by inter-relationships
2.1.available
Each manufacturer shall establish procedures to ensure that the design requirements
relating
a
1.1.3.
Createto backward
traces to design
elements
within
and are
across
Design Control
2.3. Ensure all design elements are
2.3. Ensure
all design
elements
available
device
are appropriate
address the intended use of the device, including the needs of
the user Elements
2.3.1. Store design elements by Design
Control
Guidance and
Element
2.3.1. Store design elements by Design Control Guidance Element
Guidance
andhistorical
patient. values
2.3.2. Store design elements and their
2.3.2. Store design elements and their historical values
Traceability
Reports:
Linked
design
elements

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a
1.1.4.
Create
forward
impacts
to
design
elements
within
and
across
any
organizational
device
are
appropriate
and
address
the
intended
use
of
the
device,
including
the
needs
of
the
user
3. Manage all user needs
3. Manage all user needs
procedure
3.1. Identify the source of the user needand patient.
3.1. Identify the source of the user need
2.3. The procedures shall include a mechanism for addressing incomplete requirements.
3.2. Identify all user types (groups)
3.2. Identify
all user types (groups)
Attribute
 Impact Reports: Procedure
3.3. Identify the customer (s) 2.4. The procedures shall include a mechanism for addressing ambiguous requirements.
3.3.
Identify
the
customer
(s)
1.1.5.Create forward impacts to design elements within and across any project milestone
3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements.
3.4. Profile the expected patients
Attribute
 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)
2.7.forThe
input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design
elements
within and
across
Design
Control
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
4. Manage design input requirements2.9. The approval, including the date and signature of the individual(s) approving the requirements,
4. Manage
design
input requirements
Impact
Reports:
Linked
design
elements

shall be documented.
4.1. Identify the source of the requirement
4.1. Identify the source of the requirement
1.2.
Associate
changed
design
elements
with
related
elements
2.10. Questions.
4.2. Identify the associated user need
4.2. Identify the associated user need
2.10.1.
Summarize the manufacturer's written procedure(s) for identification and
LinkofChange Design Object 4.3.
withCapture
affected
design element(s)
 control
4.3. Capture requirement description and
attributes
requirement
description and attributes
design input.
4.4. Capture acceptance criteria
4.4. from
Capture
acceptance
criteria
affected
design
element(s)
 Traceability Links and Reports
2.10.2. From what sources are design inputs sought?
4.5. Assign responsibility for each requirement
4.5. affected
Assign responsibility
for each requirement
design element(s)
 Impact Links and Reports from
4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
4.6. Manage incomplete requirements
1.2.1.Associate design element changes
with decisions, 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
2.10.3.2.
user/patient/clinical
following
Attributes:
4.9. Approve all requirements
Approve
all requirements
 Change Decision Objects4.9.with
2.10.3.3.
performance characteristics
 Disposition Attribute
2.10.3.4.
safety
5. Manage acceptance
5. Manage acceptance
 Decision Attribute
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
risk analysis
 Rationale Attribute
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.
5.3. Document the results of every user need
acceptancetoxicity
test and biocompatibility
5.3. Document the results of every user need acceptance test
 Owner Attribute
electromagnetic
compatibility (EMC)
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
 Management Approval Attribute
compatibility with accessories/auxiliary devices
5.5. Make acceptance results available 2.10.3.9.
5.5. Make acceptance results available
1.2.2.Provide associations within and across any organizational procedure
2.10.3.10. compatibility with the environment of intended use
2.10.3.11. human factors
Link on Procedure Attribute
 Change Design Object
6. Manage change
6. Traceability
Manage change
2.10.3.12. physical/chemical characteristics
6.1. Maintain history of design element changes
6.1. Maintain
of design Attribute
element changes
Change Design Object Impacts
Link history
on Procedure

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
Link on Milestone Attribute
 Change Design Object Traceability
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
2.10.3.16.
voluntary
on Milestone
Attribute
 Change Design Object Impacts
6.1.4. Maintain history within and across
any Design
Control standards
Guidance Elements
6.1.4.Link
Maintain
history within
and across any Design Control Guidance Elements
2.10.3.17.
6.2. Capture frequency and nature of element
changes manufacturing processes
natureGuidance
of element changes
1.2.4.Provide associations within6.2.
andCapture
acrossfrequency
Design and
Control
Elements
6.2.1. Provide rationale for change 2.10.3.18. sterility
6.2.1. Provide
fordesign
change elements
Linkrationale
to traced
 Change Design Object Traceability
2.10.3.19. MDRs/complaints/failures and other historical data
6.2.2. Describe decisions made
6.2.2. Describe decisions made
Change
Design
Object
Impacts
Link
to
linked
design
elements
2.10.3.20.
design
history
files
(DHFs)

6.2.3. Identify approval authority for the change
6.2.3. Identify approval authority
for the change
2.10.4.of approving
For the specific
design covered, how were the design input requirements
identified?
1.3. Mange
the change process
6.2.4. Capture date, time, and signature
authority
6.2.4. Capture date, time, and signature of approving authority
specific
design covered, how were the design input requirements reviewed
forChange Module
6.3. Identify impacted elements due to2.10.5.
a changeFor
in the
another
element
6.3. Identify impacted elements due to a change in another element
 Design
adequacy?within and across any organizational procedure
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





Design Change Reports
Object History
Object History Reports
Versions
Baselines
6.3.2. Create backward traces to design elements within and across any project milestone
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
End-to-end visual validation in a single view
22
© Telelogic AB
Systems Modeling
• Introduces formality into the definition of systems
• Specification and design visualized in diagrams
• Uses diagrams, not just pictures
• Definition of precise vocabulary across the system
• Means of reasoning about a problem and its potential solutions
• Multiple (interacting) aspects of a system are modeled
• Progressive refinement towards more detailed design
• Validation of some aspects of design through animation
• Encourages communication between different organizations
through the use of common standard notations (UML2.0)
23
© Telelogic AB
Models Bridge Layers of Requirements
Requirements layer
Statement
of need
e.g Goal / Usage
modeling
Modeling layer
Requirements layer
Stakeholder
requirements
e.g.Functional
Functional
modeling
modeling
Modeling layer
Requirements layer
System
requirements
Functional
Functional
e.g. Performance
modeling
modeling
modeling
Modeling layer
Requirements layer
24
Architectural
design
© Telelogic AB
Models and Requirements
25
•
Models and Requirements
complement each other
•
Diagrams help clarify
understanding of requirements
•
Modeling can help identify gaps
and misunderstandings
•
A formalized but flexible graphical
notation enables expressive,
‘people friendly’ diagrams
•
DOORS/Analyst: integrated
modeling with requirement
management
© Telelogic AB
Requirements Driven Development
26
•
•
Requirements must be captured and communicated to development.
•
Development activities must be driven from design and
functional requirements.
•
Relationship between requirements and development artefacts
must be established and automatically updated.
Design and functional requirements must be managed and
linked to user requirements.
© Telelogic AB
Optimizing Business Value of Development
Requirements Driven Testing
User Requirements
Acceptance testing
Specification
Functional
System testing
Specification
Design
Integration testing
System Build
27
© Telelogic AB
QUESTIONS?
28
© Telelogic AB