Requirements Management with DOORS

Download free trial

http://www-03.ibm.com/software/products/en/ratidoor

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)
Object or
Column Section
No change since baseline Heading Number Object Heading
change-bar (green / blue)

Link Indicator
(incoming
Object
and outgoing)
Identifier

Object
Changed this session
Text Current
change-bar, unsaved
(red / red) 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? Stakeholder Tests Acceptance
• link modules? Requirements Tests

• linksets?
Satisfies
What are the names
of the link modules? System Tests Functional
Requirements Tests

Standards Satisfies

Design Tests Unit

Constrained By Specification Tests

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 System Acceptance
STOP
Requirements STOP Requirements 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 Technical Reqts Design Test Cases
1. 820.30(b) Design and Development Planning 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 Each manufacturer shall establish and maintain plans that describe or reference the design1.1. Identify impacted elements due to a change in another element
and development 1.1. Identify impacted elements due to a change in another element
activities and define responsibility for implementation. activities and define responsibility for implementation.
1. Capture design and related information  Traceability Reports: consistency
1. Capturewith driving
design design
and related elements
information  Traceability Reports: consistency with driving design elements
1.1. Input electronically formatted data Reports: other design1.1. Input electronically
affected formatted data
The plans shall identify and describe the interfaces with different groups or activities that provide, or result The plans
1.2. Reference external information shall identify and describe the interfaces with different groups or activities that provide,
sources
Impact
or result elements
1.2. Reference external information sources
 Impact Reports: other design elements affected
in, input to the design and development process. in, input to the design and development process.
1.3. Reference external documentation  Links to impacted design elements 1.3. Reference external documentation  Links to impacted design elements
1.1.1. Create backward traces to design elements within and across any organizational 1.1.1. Create backward traces to design elements within and across any organizational
The plans shall be reviewed as design and development evolves. 2. The plans shall be reviewed as design and development evolves.
Store design and related information procedure 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
The plans shall “design
be updated elements”
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. The plans shall be approved as design and development evolves.  Traceability Reports: Procedure Attribute  Traceability Reports: Procedure Attribute
2.2. Organize design elements 2.2. Organize design elements
2.2.1. Organize by Design Control Guidance Element
1.1.2. Create backward traces to design elements within and across any project milestone
2.2.1. Organize by Design Control Guidance Element
1.1.2. Create backward traces to design elements within and across any project milestone
2. 820.30(c) Design Input 2. 820.30(c) Design Input
2.2.2. Organize by inter-relationships  Traceability Reports: Milestone Attribute
2.2.2. Organize by inter-relationships  Traceability Reports: Milestone Attribute
2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a 2.1. Each
2.3. Ensure all design elements are available manufacturer shall establish procedures to ensure that the design requirements relating to a
1.1.3. Create backward traces to design elements
2.3. Ensure within
all design and are
elements across Design Control
available 1.1.3. Create backward traces to design elements within and across Design Control
device are appropriate and address the intended use of the device, including the needs of the user device
2.3.1. Store design elements by Design are appropriate
Control Guidance and address the intended use of the device, including the needs of the user
Element 2.3.1. Store design elements by Design Control Guidance Element
Guidance Elements Guidance Elements
and patient. andhistorical
2.3.2. Store design elements and their patient. values 2.3.2. Store design elements and their historical values
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating  Traceability
to a Reports: Linked design elements  Traceability Reports: Linked design elements
device are appropriate and address the intended use of the device, including the needs of the user 3. Manage all user needs device are appropriate and address the intended use of the device, including the 1.1.4. needs ofCreate forward impacts3.to design
the user Manage elements within and across any organizational
all user needs 1.1.4. Create forward impacts to design elements within and across any organizational
and patient. 3.1. Identify the source of the user needand patient. procedure 3.1. Identify the source of the user need procedure
2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.3. The procedures shall include a mechanism for addressing incomplete requirements.
2.4. The procedures shall include a mechanism for addressing ambiguous requirements.
3.2. Identify all user types (groups)
2.4. The procedures shall include a mechanism for addressing ambiguous requirements.
 Impact Reports: Procedure 3.2. Identify
Attribute all user types (groups)  Impact Reports: Procedure Attribute
3.3. Identify the customer (s) 1.1.5. Create forward impacts to design3.3. Identify the customer
elements within(s)and across any project milestone 1.1.5. Create forward impacts to design elements within and across any project milestone
2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients
2.6. The design input requirements shall be documented by a designated individual(s). 2.6. The design
3.5. State the intended use of the product (family) input requirements shall be documented by a designated individual(s).  Impact Reports: Milestone Attribute
3.5. State the intended use of the product (family)  Impact Reports: Milestone Attribute
2.7. The design input requirements shall be reviewed by a designated individual(s). 2.7. The design
3.6. Capture the acceptance criteria for each user need input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and
3.6. Capture the acceptance across
criteria Design
for each Control
user need 1.1.6. Create forward impacts to design elements within and across Design Control
2.8. The design input requirements shall be approved by a designated individual(s). 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements Guidance Elements
2.9. The approval, including the date and signature of the individual(s) approving the requirements, Manage design input requirements2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.
4.
shall be documented.  Impact Reports: Linked 4. Manage
designdesign input requirements
elements  Impact Reports: Linked design elements
4.1. Identify the source of the requirement 4.1. Identify the source of the requirement
2.10. Questions. 2.10. Questions.
4.2. Identify the associated user need
1.2. Associate changed design elements with related elements
4.2. Identify the associated user need
1.2. Associate changed design elements with related elements
2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of 4.3. Capture requirement description and2.10.1. Summarize the manufacturer's written procedure(s) for identification and
attributes  control
LinkofChange Design Object 4.3. withCapture
affected design element(s)
requirement description and attributes  Link Change Design Object with affected design element(s)
design input. 4.4. Capture acceptance criteria design input.  Traceability Links and Reports 4.4. from affected
Capture design
acceptance element(s)
criteria  Traceability Links and Reports from affected design element(s)
2.10.2. From what sources are design inputs sought? 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
4.5. Assign responsibility for each requirement
2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark  thatImpact
all apply Links and Reports from
and
4.5. affected
Assign responsibility for each requirement
design element(s)  Impact Links and Reports from affected design element(s)
4.6. Manage incomplete requirements 4.6. Manage incomplete requirements
list additional aspects.) 4.7. Manage ambiguous requirements list additional aspects.) 1.2.1. Associate design element changes with decisions, rationale, and approval authority
4.7. Manage ambiguous requirements
1.2.1. Associate design element changes with decisions, rationale, and approval authority
2.10.3.1. intended use 4.8. Manage conflicting requirements 2.10.3.1. intended use information 4.8. Manage conflicting requirements information
2.10.3.2. user/patient/clinical 4.9. Approve all requirements 2.10.3.2. user/patient/clinical  Change Decision Objects4.9. with following
Approve Attributes:
all requirements  Change Decision Objects with following Attributes:
2.10.3.3. performance characteristics 2.10.3.3. performance characteristics
2.10.3.4. safety 2.10.3.4. safety  Disposition Attribute  Disposition Attribute
5. Manage acceptance 5. Manage acceptance
2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need2.10.3.5. limits and tolerances  Decision Attribute 5.1. Ensure the acceptance of every user need  Decision Attribute
2.10.3.6. risk analysis 5.2. Ensure the acceptance of every design2.10.3.6. risk analysis
input requirement  Rationale Attribute 5.2. Ensure the acceptance of every design input requirement  Rationale Attribute
2.10.3.7. toxicity and biocompatibility 2.10.3.7.
acceptancetoxicity
test and biocompatibility
5.3. Document the results of every user need  Owner Attribute 5.3. Document the results of every user need acceptance test  Owner Attribute
2.10.3.8. electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. electromagnetic compatibility (EMC)
2.10.3.9. compatibility with accessories/auxiliary devices
input requirements test
 Management Approval Attribute 5.4. Document the results of every design input requirements test
 Management Approval Attribute
5.5. Make acceptance results available 2.10.3.9. compatibility with accessories/auxiliary devices 5.5. Make acceptance results available
2.10.3.10. compatibility with the environment of intended use 2.10.3.10. compatibility with the environment of intended use 1.2.2. Provide associations within and across any organizational procedure 1.2.2. Provide associations within and across any organizational procedure
2.10.3.11. human factors 6. Manage change 2.10.3.11. human factors  Change Design Object 6. Traceability
Manage change Link on Procedure Attribute  Change Design Object Traceability Link on Procedure Attribute
2.10.3.12. physical/chemical characteristics 2.10.3.12. physical/chemical characteristics
2.10.3.13. labeling/packaging
6.1. Maintain history of design element changes
2.10.3.13. labeling/packaging
 Change Design Object Impacts
6.1. Link history
Maintain on Procedure
of design Attribute
element changes  Change Design Object Impacts Link on Procedure Attribute
6.1.1. Make complete change history available 1.2.3. Provide associations within and6.1.1. Makeany
across complete change
project history available
milestone 1.2.3. Provide associations within and across any project milestone
2.10.3.14. reliability 6.1.2. Maintain history within and across2.10.3.14. reliabilityprocedure
any organizational 6.1.2. Maintain history within and across any organizational procedure
2.10.3.15. statutory and regulatory requirements 6.1.3. Maintain history within and across2.10.3.15.
any projectstatutory
milestoneand regulatory requirements  Change Design Object Traceability Link on Milestone Attribute
6.1.3. Maintain history within and across any project milestone  Change Design Object Traceability Link on Milestone Attribute
2.10.3.16. voluntary standards 6.1.4. Maintain history within and across2.10.3.16.
any Design voluntary
Control standards
Guidance Elements  Change Design Object Impacts 6.1.4.Link on Milestone
Maintain Attribute
history within and across any Design Control Guidance Elements  Change Design Object Impacts Link on Milestone Attribute
2.10.3.17. manufacturing processes 6.2. Capture frequency and nature of element 2.10.3.17.
changes manufacturing processes 1.2.4. Provide associations within6.2. andCapture
acrossfrequency
Design and Control
natureGuidance Elements
of element changes 1.2.4. Provide associations within and across Design Control Guidance Elements
2.10.3.18. sterility 2.10.3.18. sterility
2.10.3.19. MDRs/complaints/failures and other historical data
6.2.1. Provide rationale for change
2.10.3.19. MDRs/complaints/failures and other historical data  Change Design Object Traceability 6.2.1. Provide
Linkrationale
to tracedfordesign
change elements  Change Design Object Traceability Link to traced design elements
6.2.2. Describe decisions made 6.2.2. Describe decisions made
2.10.3.20. design history files (DHFs) 2.10.3.20.
6.2.3. Identify approval authority for the change design history files (DHFs)  Change Design Object Impacts 6.2.3.Link to linked
Identify design
approval elements
authority for the change  Change Design Object Impacts Link to linked design elements
2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.4.of approving
6.2.4. Capture date, time, and signature For the specific design covered, how were the design input requirements
authority 1.3. Mange the change process
identified? 6.2.4. Capture date, time, and signature of approving authority 1.3. Mange the change process
2.10.5. For the specific design covered, how were the design input requirements reviewed for 6.3. Identify impacted elements due to2.10.5. For
in the specific design covered, how were the design input requirements reviewed forChange Module
adequacy?
a change
adequacy?
another element  Design 6.3. Identify impacted elements due to a change in another element  Design Change Module
6.3.1. Create backward traces to design elements within and across any organizational procedure
 Design Change Reports 6.3.1. Create backward traces to design elements within and across any organizational procedure
 Design Change Reports
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
 Object History Reports  Object History Reports
 Versions  Versions
 Baselines  Baselines

Requirements Management with DOORS 16

Link Analysis

Traceability Analysis
• Follows incoming links (i.e. from high-level to low-
level 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?
Use Impact Analysis for the Stakeholder Tests Acceptance
Requirements Tests
Second Unit Test (depth 3).
• Which stakeholder Satisfies

requirements are affected? System Tests Functional

Use the Analysis Wizard to show Requirements Tests

which stakeholder requirements Satisfies

are not verified by unit tests?
Design Tests Unit
Specification Tests

Standards
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

System Tests Functional

Requirements Tests

Satisfies

Design Tests Unit

Specification Tests

Standards
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