«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
Top Related