SEG 3101
Requirements Management with DOORS
Adapted from presentations from
Telelogic and Amyot 2005-2012
Preparation for this lab
• Make sure you can run DOORS
• Download DOORS_101.dpa from TWiki
and save it to your desktop
http://cserg0.site.uottawa.ca/seg/bin/view/SEG3201/WebHome
Requirements Management with DOORS
2
Benefits of Requirements Management
Traceability from highest level requirements to implementation
• Established via links through a requirements database
• Links between requirements and design models, tests, code…
Impact assessments of proposed changes
• Analysis tools let you see which other requirements (and other
linked artefacts) will be affected by a change
Controlled access to current project information
• A shared database ensures that all users are working with
current data
• A central repository allows all users to see the information that
they need to see
Change control
• A change proposal system implements a controlled process for
managing change
Requirements Management with DOORS
3
DOORS database view (v8.x)
Deleted Folder
Folders
Formal Modules
Projects
Link modules
Requirements Management with DOORS
4
Displayed Information (v8.2 / v8.3)
Column
“No change since baseline” Heading
change-bar (green / blue)
Object or
Section
Number
Object Heading
Link Indicator
(incoming
and outgoing)
Object
Identifier
“Changed this session”
change-bar, unsaved
(red / red)
Object
Text
Current
Object
“Changed since baseline”
change-bar, saved (yellow / yellow)
Requirements Management with DOORS
5
Heading Objects and Text Objects
Hierarchical organization of objects
Heading Object
• Has a value for Object Heading, but not for Object Text
• Provides context for the objects below it
Text Object
• Has a value for Object Text, but not for Object Heading
• Requirements are entered in text objects
• Should be leaf objects in the module hierarchy
No more than one requirement in a text object
Requirements Management with DOORS
6
Shortcuts
Ctrl-N … insert object at same level
Ctrl-L … insert object below current level
Ctrl-H … edit object in object heading mode
Ctrl-T … edit object in object text mode
Ctrl-C … copy current object only (without hierarchy)
Ctrl-V … paste after current object
Ctrl-X … cut current object with hierarchy
Ctrl-Z …undo
Requirements Management with DOORS
7
Attributes for Objects, Links, and Modules
Attributes allow additional information to be associated
with each requirement (object), link, or module
Requirements Management with DOORS
8
Examples for Object Attributes
Absolute Number, Created By, Last Modified On
• Automatically created by DOORS
Source
• Who specified the requirement?
Priority
• What is the priority of this requirement?
Verifiability, Safety, …
• Is this requirement verifiable, safety-critical, …?
Review
• Review status of this requirement
Rationale
Requirements Management with DOORS
9
Link Concepts
A relationship between two objects in the DOORS
database is established using a link
Source and Target Objects
• Source is the “from” object, target is the “to” object
Links can be followed in either direction
Requirements Management with DOORS
10
Link Concepts
Links are stored in link modules
• Name of link module indicates type of link
• Some link information is stored with source object (i.e.
cannot delete object with incoming links)
Linkset
• Links are grouped into linksets
• A linkset contains all links of a specific type which exist
for one pair of formal modules
• Link modules may contain several linksets
Requirements Management with DOORS
11
Schema for Basic Project
How many
• formal modules?
• link modules?
• linksets?
What are the names
of the link modules?
Standards
Constrained By
Stakeholder
Requirements
Tests
Acceptance
Tests
Tests
Functional
Tests
Tests
Unit
Tests
Satisfies
System
Requirements
Satisfies
Design
Specification
Requirements Management with DOORS
12
Link Direction Considerations
Primary reason for choice of link direction is access
rights
• User needs write access to source object (e.g. standards
document cannot be source because designer does not
have write access)
• User needs only read access to target object
Secondary reason for choice of link direction is
consistency and built-in reporting capabilities
• Consistent bottom-up (recommended) or top-down link
direction allows convenient multi-level traceability
reporting
Requirements Management with DOORS
13
Enforcing Schema by Restricting Links
Set the following options in File - Module Properties –
Linksets to ON (for all formal modules)
• Only allow outgoing links as specified in the above list
• Mandatory
Satisfies
Stakeholder
Requirements
STOP
System
Requirements
STOP
Acceptance
Tests
If these options are not set, DOORS will create a
default link module (DOORS Links)
• Using this catch-all link module is not recommended
Requirements Management with DOORS
14
Exercise – Enforcing Schema
Create three formal modules: A, B, C
Create two objects in each module (A1, A2; B1, …)
Create a link from A1 to B1 (use drag & drop)
• Which link modules were created?
• Which linksets were created?
Create link module Test
Create a mandatory linkset in module A (File – Module Properties
– Linksets) for links to module B using link module Test
Create a link from A2 to B2 – what happened?
Create a link from A1 to C1 – what happened?
Set option “Only allow outgoing links as specified in the above list”
to ON in module A (File – Module Properties – Linksets)
Create a link from A2 to C2 – what happened?
Requirements Management with DOORS
15
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
Input electronically
Impact
Reports: other design1.1.
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?
2.
3.
4.
5.
6.
The plans shall be reviewed as design and development evolves.
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.
Each
manufacturer
shall
establish
procedures
to
ensure
that
the
design
requirements
relating
to
a
2.3. Ensure all design elements are available
2.3. Ensure
all design
elements
available
1.1.3. Create backward traces to design
elements
within
and are
across
Design Control
device
are appropriate
address the intended use of the device, including the needs of the user
2.3.1. Store design elements by Design
Control
Guidance and
Element
2.3.1. Store design elements by Design Control Guidance Element
Guidance Elements
andhistorical
patient. values
2.3.2. Store design elements and their
2.3.2. Store design elements and their historical values
Reports: Linked
design elements
 Traceability
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating
to a
Create
forward impacts3.to design
within and across any organizational
device are appropriate and address the intended use of the device, including the 1.1.4.
needs of
the user
Manage all user needs
Manage elements
all user needs
and patient.
procedure
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.
3.2. Identify all user types (groups)
3.2. Identify
all user types (groups)
Attribute
 Impact Reports: Procedure
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
3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements.
3.4. Profile the expected patients
Impact
Reports:
Milestone
Attribute

2.6.
The
design
input
requirements
shall
be
documented
by
a
designated
individual(s).
3.5. State the intended use of the product (family)
3.5. State
the intended use of the product (family)
2.7.
The
design
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 for each 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
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
 Impact Reports: Linked
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
Links and Reports from
design element(s)
 thatImpact
2.10.3.
Do
design
input
procedures
cover
the
relevant
aspects,
such
as:
(Mark
all
apply
and
4.6. Manage incomplete requirements
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
with
following
Attributes:
4.9. Approve all requirements
Approve
all requirements
 Change Decision Objects4.9.
2.10.3.3.
performance characteristics
 Disposition Attribute
2.10.3.4.
safety
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.
acceptance results available
1.2.2. Provide associations within5.5.
andMake
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
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
6.1.1.
Makeany
complete
change
history available
1.2.3.
Provide
associations
within
and
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
For
specific
design covered, how were the design input requirements reviewed
forChange Module
6.3. Identify impacted elements due to2.10.5.
a change
in the
another
element
6.3. Identify impacted elements due to a change in another element
 Design
adequacy?
6.3.1. Create backward traces to design elements
within and across any organizational procedure
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
Requirements Management with DOORS
16
Link Analysis
Traceability Analysis
• Follows incoming links (i.e. from high-level to lowlevel assuming bottom-up link direction)
Impact Analysis
• Follows outgoing links (i.e. from low-level to high-level
assuming bottom-up link direction)
Analysis Wizard
Suspect Links
• Suspect link indicator
• Clear suspect link
Requirements Management with DOORS
17
Exercise – Link Analysis
Use Trace Analysis for “S333” in Standards (depth 3).
• Which unit tests are in the trace?
Stakeholder Tests
Acceptance
Use Impact Analysis for the
Requirements
Tests
“Second Unit Test” (depth 3).
Satisfies
• Which stakeholder
requirements are affected?
Tests
System
Functional
Tests
Use the Analysis Wizard to show Requirements
which stakeholder requirements
Satisfies
are not verified by unit tests?
Tests
Design
Specification
Standards
Unit
Tests
Constrained By
Requirements Management with DOORS
18
Exercise – Suspect Links
Make a change to the “Third Design Specification”
• Where would you expect
suspect links to appear?
Stakeholder Tests
Acceptance
Requirements
Tests
Clear the suspect links
Satisfies
Tests
System
Requirements
Functional
Tests
Satisfies
Tests
Design
Specification
Standards
Unit
Tests
Constrained By
Requirements Management with DOORS
19
Filter, Sort, View, Report
Filter objects
• According to properties of an object’s attributes, links,
position in hierarchy (leaf or not leaf), and columns
Sort objects
• According to an object’s attribute values
View
• Defines display layout (columns, filters, sorts, …)
• Module-specific (saved with module)
Report
• Combines a view with a page setup for printing
• Report Wizard
Requirements Management with DOORS
20
Exercises – Filter, Sort, and View
Filter “Design Specifications” so that all headings are
not shown
Clear filter
Filter “Design Specifications” to find out all objects
without a link to “Unit Tests”
Insert a column for the Priority attribute
Sort the result by priority.
Save as view “My view”
Load the standard view
Load “My view”
Requirements Management with DOORS
21
DOORS/Analyst: Integration with UML 2.0
Linkable UML 2.0 diagrams and
element objects, via the Analyst
plug-in (Tau G2 UML 2.0 editor)
Requirements Management with DOORS
22
DOORS/Analyst
If DOORS/Analyst is installed, you can:
• Explore the Analyst menu in DOORS
• Create a module and then select Analyst --> Enable
Analyst
• You should then be allowed to embed UML diagrams
via the Analyst menu
Gestion des exigences avec DOORS
23
URNtoDOORS: Integration with URN
Linkable GRL/UCM diagrams
and element objects, via the
DXL export function in the
jUCMNav tool
Requirements Management with DOORS
24
jUCMNav-URN Integration
See the documentation and demos on Twiki:
• http://jucmnav.softwareengineering.ca/twiki/bin/view/ProjetSEG/D
oorsExport
You must install a new DOORS library to import URN models:
• http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/Ins
tallingTheDXLLibrary
Gestion des exigences avec DOORS
25
For Your Project…
You can have a simpler approach:
• Export your diagrams (with jUCMNav or another tool)
• Include them in a new DOORS module.
• Manually enumerate the important elements (goals,
scenarios, etc.) included in these diagrams.
• Create traceability links between your requirements and
these elements.
Gestion des exigences avec DOORS
26
See Also
Seilevel’s Evaluations of Requirements Management
Tools: Summaries and Scores
• http://www.seilevel.com/wpcontent/uploads/RequirementsManagementToolWP_2.pdf
• DOORS ranks in the middle of the list, according to their needs and criteria.
• We can do everything in DOORS, it is a popular and robust tool, but its
usability is weak, especially in terms of modelling.
Gestion des exigences avec DOORS
27