«SEG3101»

S. SoméU. Ottawa

SEG 3101SEG 3101

Requirements Management with DOORSRequirements Management with DOORS

Adapted from presentations from Telelogic and Amyot 2005-2012

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 2

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 3

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 changeControlled 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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 4

DOORS database view (v8.x)

Deleted Folder

Link modules

Folders

Projects Formal Modules

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 5

ColumnHeading

CurrentObject

Object Identifier

“No change since baseline” change-bar (green / blue)

“Changed this session”change-bar, unsaved

(red / red)

Object or Section Number

“Changed since baseline” change-bar, saved (yellow / yellow)

Object Heading

Object Text

Link Indicator(incoming and outgoing)

Displayed Information (v8.2 / v8.3)

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 6

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 7

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 8

Attributes for Objects, Links, and Modules

Attributes allow additional information to be associated with each requirement (object), link, or module

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 9

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 10

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 11

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 12

Schema for Basic Project

How many

• formal modules?

• link modules?

• linksets?

What are the namesof the link modules?

StakeholderRequirements

SystemRequirements

Design Specification

AcceptanceTests

FunctionalTests

Tests

Tests

Tests

Satisfies

Satisfies

UnitTests

Standards

Constrained By

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 13

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 14

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

If these options are not set, DOORS will create a default link module (DOORS Links)

• Using this catch-all link module is not recommended

StakeholderRequirements

SystemRequirements

AcceptanceTests

Satisfies

STOPSTOP

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 15

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?

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 16

Traceability View

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, 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 Input2.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 userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand 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 ofdesign 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 use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.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?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

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 elements1.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 ControlGuidance Elements Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure 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 ControlGuidance 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

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, 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 Input2.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 userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand 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 ofdesign 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 use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.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?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

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 elements1.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 ControlGuidance Elements Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure 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 ControlGuidance 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

User Reqts Technical Reqts Test CasesDesign

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 17

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 18

Exercise – Link Analysis

Use Trace Analysis for “S333” in Standards (depth 3).

• Which unit tests are in the trace?

Use Impact Analysis for the “Second Unit Test” (depth 3).

• Which stakeholder requirements are affected?

Use the Analysis Wizard to showwhich stakeholder requirements are not verified by unit tests?

StakeholderRequirements

SystemRequirements

Design Specification

AcceptanceTests

FunctionalTests

Tests

Tests

Tests

Satisfies

Satisfies

UnitTests

StandardsConstrained By

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 19

Exercise – Suspect Links

Make a change to the “Third Design Specification”

• Where would you expect suspect links to appear?

Clear the suspect linksStakeholder

Requirements

SystemRequirements

Design Specification

AcceptanceTests

FunctionalTests

Tests

Tests

Tests

Satisfies

Satisfies

UnitTests

StandardsConstrained By

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 20

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 21

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”

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 22

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)

«SEG3101»

S. SoméU. Ottawa

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

«SEG3101»

S. SoméU. Ottawa

Requirements Management with DOORS 24

URNtoDOORS: Integration with URN

Linkable GRL/UCM diagrams and element objects, via the DXL export function in the jUCMNav tool

«SEG3101»

S. SoméU. Ottawa

jUCMNav-URN Integration

See the documentation and demos on Twiki:

•http://jucmnav.softwareengineering.ca/twiki/bin/view/ProjetSEG/DoorsExport

You must install a new DOORS library to import URN models:

•http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/InstallingTheDXLLibrary

Gestion des exigences avec DOORS 25

«SEG3101»

S. SoméU. Ottawa

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

«SEG3101»

S. SoméU. Ottawa

See Also

Seilevel’s Evaluations of Requirements Management Tools: Summaries and Scores •http://www.seilevel.com/wp-content/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