Dynamic Object-Oriented Requirements System (DOORS)

2. Discussion Topics
•What is requirements management (RM)
•Who uses RM
•What is DOORS
•How do you use DOORS
•What is DOORS Web Access

3. What is requirements management?
“The purpose of requirements management is to establish
a common understanding between the customer and the
… project ... This agreement with the customer is the
basis for planning and managing the … project.”
The Capability Maturity Model for Software (CMM ) from the Software
Engineering Institute at Carnegie Mellon University.
- www.sei.cmu.edu/cmm
®

4. So What Are Requirements?
Requirements
Objective
Goal
Aim
Regulation
Criterion
Need
Feature
Function
Rule
Risk

5. Using DOORS in the RM market
•Competitive time to market with high quality are required for these products
•FCC and government regulations of public utilities provide quality and testing standards
•RM not perceived to be mandatory
Telecom equipment manufacturers
Time to market and Compliance
Driven
•SEC, legal and business liability issues require these business-critical applications comply with
requirements, standards and regulations
•Focus on testing, with requirements defining the basis for test
•Quality if of utmost concern, with loss of business on the line
•RM tools are not perceived to be mandatory, but have been following the rising use of application
test tools
Complex IT including
Finance and Telecom
Service Providers
Market and Quality Driven
•FAA, FDA, FTC, AUTOSAR, SPICE and legal liability issues require these mission critical
products to prove compliance to requirements, standards and regulations
•Stringent testing is required
•Quality is of utmost concern taking precedence over cost and time
•RM tools perceived to be mandatory
Aerospace, Automotive, and Medical
Instrumentation
Compliance and Quality Driven
•Government Contract awarded based on SEI CMM/CMMI maturity level
•Time and cost are usually determined at the beginning of each project phase
•Highly concerned about efficiency, standardization of tools and process
•RM tools perceived to be mandatory (DOORS may even be specified)
Military/Defense
Contractor/Government
Contracts Driven
DriversOrganization Type

6. Source: The Seattle Times
Boeing 787: # of engineers are 2005 projections and may not include all engineering specialties. Production workers are not included.
Boeing 787 Dreamliner
Number of parts: 6 million
Peak number of suppliers: 2,600
An Example of the Challenge of Managing Complexity
Boeing Commercial Aircraft: 787 Development Program
Who makes the parts and where
the engineering jobs are:
CAD models: 20,000
Design changes per year: 150,000

7. Customers examples…

8. DXL scripting
Data
Exchange
Access Control
Roles
Configuration
Product
Components
DOORS
Dynamic Object Oriented Requirements System

9. Architectural Features
•Flexible client configuration
•Client-server architecture
•Networked and off-line working
•Web interface (DOORS Web Access)
•Interfaces to other lifecycle tools
•Support for Windows, Unix and Linux platforms

10. Simplified Processing Model
DOORS Client
DOORS Server
1
3
2
Client retrieves module from database
Client processes module locally
Client returns module to database
1
2
3

11. Client/Server Architecture (Simplified)
DOORS
Data
D
D
B
S
Windows /
Unix
Directory
Tree
DOORS
Web
Access
DOORS
on Windows
TCP/IP
Local filesystem
Windows
Service /
Unix
Process
TCP/IP
Web
Browser
TCP/IPTCP/IP
DOORS
App.
Server
TCP/IP
Client

12. Typical Network Installation

13. Configuring the registry and using command-line switches
for the Rational DOORS client
•Registry settings
When you start Rational DOORS on a Windows computer, it uses
the default configuration information in the registry.

14. DOORS directories

15. Configuring the registry and using command-line switches
for the Rational DOORS client
•Starting Rational DOORS from a shortcut
On Microsoft Windows® computers, you can use a shortcut to run
Rational DOORS.
•Command-line switches for the Rational DOORS client
You can use command-line switches to override the registry settings
when the Rational DOORS starts.

16. •DOORS database flat file system repository for component information
•Projects and Folders used to organize and structure the data in the database and can be created
anywhere in the database hierarchy.
•Module contain objects that are defined by their attributes.
•Object each row in a module is an object. Objects can be arranged in a hierarchical structure in
formal modules. The data in objects is stored in attributes.
•Attributes & Types information about modules and objects is stored in attributes. Attributes have
three parts: attribute type, attribute definition, attribute value.
•Links create relationships between objects to provide give you traceabilityand also allow you to
manage change.
•Forms You can create forms that include specified attributes that you want to edit
•Discussions allow reviewers to exchange views about the content of a module or the content of an
object in a module. Instead of setting up linked review documents, or adding new text attributes to the
module under review, Rational DOORS allows you to maintain running discussions about objects and
modules. The discussions are presented to you as part of the properties of the object or module.
•Partition used to send data to a different database to be viewed or edited and then returned.
•RIF Use the Requirements Interchange Format (RIF) to exchange requirement information between
requirements databases and requirements tools.
•
CPS As your projects proceed, it is inevitable that you will need to change requirements. Any
changes, however, are bound to affect other requirements; a single change to one requirement can
cause a cascade of potential changes to requirements throughout your system. Use the change
proposal system (CPS) to manage changes to the requirements in your system.
•DXL DOORS extension Language
Terminology

17. What is DOORS ?
•A RM toolset that enables users to select, create, or
relate requirements in an easy to navigate user
interface.
It features:
•multi-user document access
•extensive access controls
•filtering and sorting of data
•requirement linking
•traceability & impact analysis
•change control & tracking
•custom features via DXL scripting

18. •Database
•Projects and Folders
•Modules
Views
Attribute
Links
DOORS Architecture

19. DOORS Architecture - Modules
•Modules contain a hierarchy of objects
•Objects contain attribute values
•Objects can be linked

20. Doors Administrator Account
•A unique account for emergency administration database configuration
•Powers of Database Manager plus
•Perform integrity checks on Database
•Restrict the Deletion of Baselines
•No access restrictions
•Can restore DOORS user/group archives
•Can enable the restricting of using DXL
•Can set DOORS login policies:
•System username
•LDAP

21. User types
Standard User
can work with Rational
DOORS data
Project Manager
In addition to Standard user powers:
•Partition data
•Archive data
•Create and manage groups

Database Manager
In addition to project manager
powers:
•Create projects
•Create and manage users
•Manage the database
Custom User
In addition to Standard user powers,
any combination of the following
powers:
•Create projects
•Partition data
•Archive data
•Create and manage groups
•Create and manage users
•Manage the database

22. DOORS Entity Relationships

• Standard
• Project Manager
• Database
Manager
• Custom
• Create Project
• Archive Data
• Partition Data
• Create Groups
• Create Users
• Manage Database
• Read
• Create
• Modify
• Delete
• Admin
• Project
• Folder
• Module
• Object
• Individuals
• Groups
• Everyone Else
apply to
have
are ofhave
Items Access Rights Users User Types Powers

23. DOORS Web Access
•A Rich Internet Application providing an ALTERNATIVE method of
accessing your DOORS database.
•A way to spread requirements to users with less DOORS knowledge
or training
It features:
•Full database explorer
•Module/Multi-Module Display
•Full attribute access pane
•Discussion Support
•Brows-able links
•Find within a Module
•Add filter conditions to limit display of information
•Not a replacement for DOORS desktop client

24. DOORS Web Access: Architecture
DWA Server
DWA Broker
Interop Server
Cluster
Interop Server
Cluster
Interop Server
Cluster
TCP
TCP
DOORS
Database
TCP
Flex LM
TCP
TCP
HTTP(S) TCP
Each Interop Server can
serve multiple users
DOORS DB can be
used concurrently
with DOORS Clients
Browser uses
DOJO and JS
(Zero Footprint)
Broker provides
communications to DOORS
Interoperation Servers
DOORSDWA

25. Data Exchange
•Archive / Restore
•Partition / Rejoin ( dynamic data exchange)
•Import / Export ( MS Word, RTF, Excel )
•Integrations Rose, Synergy Change, HP Quality Center
•Requirements Interchange Format
•Integrations using Rational Workbench for Collaborative Lifecycle
Management

26. Using DXL (the Rational DOORS Extension Language)
•Setting up DXL security
You can increase security by controlling how DXL is used in the
database. You can control whether all users can run and edit DXL
scripts, and also restrict which types of DXL scripts can be run.
•The DXL library
The DXL library contains a selection of DXL programs that you can
run in the DXL interaction window, or use as attribute DXL or layout
DXL.
•Developing DXL programs
You can use the DXL Interaction window to develop small DXL
programs.

27. Roadmap
DOORS and DOORS Web Access
September 2010: DOORS 9.3
RTC, ClearQuest, Change integrations using OSLC-RM and OSLC-CM
Embedded document generation with common reporting components
Additional translations: German, French, and Russian
SSL communication with certificate based authentication (PKI)
September 2010: DOORS Web Access 1.4
Enhanced filtering for improved analysis/review
UI harmonization with IBM Rational Jazz clients
Q4 2010: DOORS Enterprise Technology Preview
Common Jazz based requirement server
COTS database
2009 2010 2011+

28. Backup material

29. Factors That Contributed to RMs
Importance
•Complexity – Software is more pervasive and arbitrarily complex
•Globalization – Organizations are more global through acquisitions,
mergers, partnerships
•Competition – Pressure to deliver better products to market more
quickly
•Compliance – Companies are obligated to provide evidence that
they comply with regulations such as FDA regulations and
Sarbanes-Oxley

30. RM is a lifecycle activity
Configuration/Change Management Tools
Metrics Tools
Project Management Tools
Documentation Tools
Requirements Management & Traceability Tools
Requirements
Capture &
Engineering
Analysis
& Design
Tools
Modeling
Tools
Simulation
Tools
Coding
Tools
Testing
Tools

31. Why bother with Requirements?
•To show what results the users want
•To communicate and focus team members on clear goals
•To tell decision-makers what is required vs. desired
•To allow the design to be optimized
•To supply confidence in the system THROUGHOUT its
development
•To check that the system and all its parts do what is wanted
•To prevent over design or omitted needs
•To control development and outsourcing
To reduce the risk of project failure

32. 32
The Benefits of Requirements Management
•Satisfaction: real business needs met
•Integration: the pieces work together
•Testability: know what to test the delivery items against
•Traceability: see dependencies and relationships between requirements
•Communication: consistent ideas of what the solution is for
•Visibility: managers can take a global view
•Change control: the impact of change can be assessed
•Quality: we know what quality means for the business
•Optimization: we deliver only what is wanted
•Compliance: demonstrate compliance with regulatory authorities and S-Ox.

33. Symptoms of a Broken Requirements
Management Process
•The status of the project is never clear until project milestones are missed
•Little formal development process
•The objectives always seem to change at the worst times
•Change is very costly and time consuming
•Difficulty communicating intent between departments
•Over-engineering solutions which is costly
•Trouble testing against original intent and stated need
•Never sure whether tests are full and complete
•Test cycles are often too long and costly
•Customers often include design in the requirements
•Difficulty organizing requirements into smaller manageable sets

34. Key Concepts of Requirements
Management
•Communication – sharing of requirements across an organization
•Collaboration – via traceability to those requirements from any
phase or levels
•Validation – accomplished through the linking of test cases to show
how the requirement was proven

35. Traceability
•How requirements are satisfied
•How requirements are tested
•The impact of changing requirements
•The impact of test failure

36. 1. 820.30(b) Design a nd Deve lopme nt Planning
Each m anufac ture r shall establish and m aintain plans that de sc ribe or r efer ence the design and developm ent
ac tivities a nd de fine responsibility for implem entation.
The plans shall identif y a nd describe the interf ace s with diffe rent groups or a ctivities tha t pr ovide, or result
in, input to the de sign a nd deve lopme nt process.
The plans shall be revie wed as design and deve lopm ent evolves.
The plans shall be updated as design and developm ent evolves.
The plans shall be appr ove d a s design and development evolves.
2. 820.30(c ) Design Input
2.1. Ea ch ma nufa cturer shall establish pr ocedures to e nsure that the de sign requir eme nts relating to a
de vice are appr opriate and address the inte nded use of the device, inc luding the needs of the user
a nd pa tient.
2.2. Ea ch ma nufa cturer shall m aintain procedures to e nsure that the de sign requir eme nts relating to a
de vice are appr opriate and address the inte nded use of the device, inc luding the needs of the user
a nd pa tient.
2.3. The proc edures sha ll inc lude a m echanism for addre ssing incom plete r equirem ents.
2.4. The proc edures sha ll inc lude a m echanism for addre ssing am biguous requir eme nts.
2.5. The proc edures sha ll inc lude a m echanism for addre ssing conf licting requirem ents.
2.6. The de sign input r equire ments shall be doc um ented by a designate d individual(s).
2.7. The de sign input r equire ments shall be reviewed by a de signated individual(s).
2.8. The de sign input r equire ments shall be approved by a designa te d individual( s).
2.9. The appr ova l, including the date and signature of the individual(s) approving the requir eme nts,
shall be documented.
2.10. Que stions.
2.10.1. Sum ma riz e the ma nufa cture r's written procedure( s) f or identification and contr ol of
design input.
2.10.2. Fr om what sourc es are design inputs sought?
2.10.3. Do design input procedures cover the relevant aspects, such as: ( Ma rk all that apply and
list additiona l a spec ts.)
2.10.3.1. intended use
2.10.3.2. user /patient/clinic al
2.10.3.3. pe rform ance c haracter istics
2.10.3.4. saf ety
2.10.3.5. limits and tole rance s
2.10.3.6. risk analysis
2.10.3.7. toxicity and bioc om patibility
2.10.3.8. ele ctroma gne tic c om patibility ( EMC)
2.10.3.9. compatibility with ac cessor ie s/auxiliary device s
2.10.3.10. compatibility with the envir onm ent of intended use
2.10.3.11. hum an fac tors
2.10.3.12. physical/c hemica l cha racter istics
2.10.3.13. labe ling/pa ckaging
2.10.3.14. relia bility
2.10.3.15. statutory a nd re gulatory requirem ents
2.10.3.16. volunta ry standar ds
2.10.3.17. manufa ctur ing processes
2.10.3.18. sterility
2.10.3.19. MDRs/c omplaints/f ailure s a nd other historica l data
2.10.3.20. de sign histor y files (DHFs)
2.10.4. For the specific design cover ed, how were the design input re quirem ents identif ied?
2.10.5. For the specific design cover ed, how were the design input re quirem ents r evie wed f or
ade qua cy?
Com ply w ith FD A D esign C ontrol G uidance G M P R egula tion
1. Capture design and re la ted inform ation
1.1. Input electronic ally form atted data
1.2. Ref ere nce exter nal inform ation source s
1.3. Ref ere nce exter nal docum entation
2. Store de sign and related inf orm ation
2.1. Identify and ta g de sign infor ma tion a s unique “design elem ents”
2.2. O rganize de sign elem ents
2.2.1. O rganize by D esign C ontr ol G uidance Elem ent
2.2.2. O rganize by inter -re la tionships
2.3. Ensur e all de sign elem ents ar e available
2.3.1. Stor e design ele me nts by De sign Control G uidanc e Ele me nt
2.3.2. Stor e design ele me nts and the ir historical value s
3. Ma nage a ll use r needs
3.1. Identify the sourc e of the user need
3.2. Identify all user types (groups)
3.3. Identify the c ustom er (s)
3.4. Prof ile the expe cted pa tients
3.5. State the intende d use of the product (fam ily)
3.6. Capture the a cce pta nc e criteria for e ach user nee d
4. Ma nage de sign input requir em ents
4.1. Identify the sourc e of the r equireme nt
4.2. Identify the a ssociated user ne ed
4.3. Capture r equirem ent de sc ription a nd a ttribute s
4.4. Capture a cce pta nce cr iter ia
4.5. A ssign responsibility f or ea ch requir em ent
4.6. Ma nage incomplete re quire me nts
4.7. Ma nage am biguous requirem ents
4.8. Ma nage conflicting re quire me nts
4.9. A pprove all r equireme nts
5. Ma nage a cce ptanc e
5.1. Ensur e the acc eptance of eve ry user need
5.2. Ensur e the acc eptance of eve ry de sign input requirem ent
5.3. D ocum ent the re sults of e very use r need a cceptance te st
5.4. D ocum ent the re sults of e very design input require ments test
5.5. Ma ke acc eptance results available
6. Ma nage c hange
6.1. Ma intain history of design e le ment changes
6.1.1. Make com ple te c hange histor y available
6.1.2. Maintain history w ithin and a cross a ny orga niz ational proce dure
6.1.3. Maintain history w ithin and a cross a ny projec t m ilestone
6.1.4. Maintain history w ithin and a cross a ny D e sign Control Guidance Ele ments
6.2. Capture f requenc y and nature of e le me nt change s
6.2.1. Provide ra tionale for cha nge
6.2.2. D esc ribe dec isions m ade
6.2.3. Identif y approva l a uthority for the c hange
6.2.4. Capture da te , time , and signature of approving a uthority
6.3. Identify im pacted e lem ents due to a cha nge in another elem ent
6.3.1. Crea te backw ar d tr ace s to design elem ents w ithin and ac ross any organizational pr ocedure
6.3.2. Crea te backw ar d tr ace s to design elem ents w ithin and ac ross any projec t 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 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
1. 820.30(b) Design a nd Deve lopme nt Planning
Each m anufac ture r shall establish and m aintain plans that de sc ribe or r efer ence the design and developm ent
ac tivities a nd de fine responsibility for implem entation.
The plans shall identif y a nd describe the interf ace s with diffe rent groups or a ctivities tha t pr ovide, or result
in, input to the de sign a nd deve lopme nt process.
The plans shall be revie wed as design and deve lopm ent evolves.
The plans shall be updated as design and developm ent evolves.
The plans shall be appr ove d a s design and development evolves.
2. 820.30(c ) Design Input
2.1. Ea ch ma nufa cturer shall establish pr ocedures to e nsure that the de sign requir eme nts relating to a
de vice are appr opriate and address the inte nded use of the device, inc luding the needs of the user
a nd pa tient.
2.2. Ea ch ma nufa cturer shall m aintain procedures to e nsure that the de sign requir eme nts relating to a
de vice are appr opriate and address the inte nded use of the device, inc luding the needs of the user
a nd pa tient.
2.3. The proc edures sha ll inc lude a m echanism for addre ssing incom plete r equirem ents.
2.4. The proc edures sha ll inc lude a m echanism for addre ssing am biguous requir eme nts.
2.5. The proc edures sha ll inc lude a m echanism for addre ssing conf licting requirem ents.
2.6. The de sign input r equire ments shall be doc um ented by a designate d individual(s).
2.7. The de sign input r equire ments shall be reviewed by a de signated individual(s).
2.8. The de sign input r equire ments shall be approved by a designa te d individual( s).
2.9. The appr ova l, including the date and signature of the individual(s) approving the requir eme nts,
shall be documented.
2.10. Que stions.
2.10.1. Sum ma riz e the ma nufa cture r's written procedure( s) f or identification and contr ol of
design input.
2.10.2. Fr om what sourc es are design inputs sought?
2.10.3. Do design input procedures cover the relevant aspects, such as: ( Ma rk all that apply and
list additiona l a spec ts.)
2.10.3.1. intended use
2.10.3.2. user /patient/clinic al
2.10.3.3. pe rform ance c haracter istics
2.10.3.4. saf ety
2.10.3.5. limits and tole rance s
2.10.3.6. risk analysis
2.10.3.7. toxicity and bioc om patibility
2.10.3.8. ele ctroma gne tic c om patibility ( EMC)
2.10.3.9. compatibility with ac cessor ie s/auxiliary device s
2.10.3.10. compatibility with the envir onm ent of intended use
2.10.3.11. hum an fac tors
2.10.3.12. physical/c hemica l cha racter istics
2.10.3.13. labe ling/pa ckaging
2.10.3.14. relia bility
2.10.3.15. statutory a nd re gulatory requirem ents
2.10.3.16. volunta ry standar ds
2.10.3.17. manufa ctur ing processes
2.10.3.18. sterility
2.10.3.19. MDRs/c omplaints/f ailure s a nd other historica l data
2.10.3.20. de sign histor y files (DHFs)
2.10.4. For the specific design cover ed, how were the design input re quirem ents identif ied?
2.10.5. For the specific design cover ed, how were the design input re quirem ents r evie wed f or
ade qua cy?
Com ply w ith FD A D esign C ontrol G uidance G M P R egula tion
1. Capture design and re la ted inform ation
1.1. Input electronic ally form atted data
1.2. Ref ere nce exter nal inform ation source s
1.3. Ref ere nce exter nal docum entation
2. Store de sign and related inf orm ation
2.1. Identify and ta g de sign infor ma tion a s unique “design elem ents”
2.2. O rganize de sign elem ents
2.2.1. O rganize by D esign C ontr ol G uidance Elem ent
2.2.2. O rganize by inter -re la tionships
2.3. Ensur e all de sign elem ents ar e available
2.3.1. Stor e design ele me nts by De sign Control G uidanc e Ele me nt
2.3.2. Stor e design ele me nts and the ir historical value s
3. Ma nage a ll use r needs
3.1. Identify the sourc e of the user need
3.2. Identify all user types (groups)
3.3. Identify the c ustom er (s)
3.4. Prof ile the expe cted pa tients
3.5. State the intende d use of the product (fam ily)
3.6. Capture the a cce pta nc e criteria for e ach user nee d
4. Ma nage de sign input requir em ents
4.1. Identify the sourc e of the r equireme nt
4.2. Identify the a ssociated user ne ed
4.3. Capture r equirem ent de sc ription a nd a ttribute s
4.4. Capture a cce pta nce cr iter ia
4.5. A ssign responsibility f or ea ch requir em ent
4.6. Ma nage incomplete re quire me nts
4.7. Ma nage am biguous requirem ents
4.8. Ma nage conflicting re quire me nts
4.9. A pprove all r equireme nts
5. Ma nage a cce ptanc e
5.1. Ensur e the acc eptance of eve ry user need
5.2. Ensur e the acc eptance of eve ry de sign input requirem ent
5.3. D ocum ent the re sults of e very use r need a cceptance te st
5.4. D ocum ent the re sults of e very design input require ments test
5.5. Ma ke acc eptance results available
6. Ma nage c hange
6.1. Ma intain history of design e le ment changes
6.1.1. Make com ple te c hange histor y available
6.1.2. Maintain history w ithin and a cross a ny orga niz ational proce dure
6.1.3. Maintain history w ithin and a cross a ny projec t m ilestone
6.1.4. Maintain history w ithin and a cross a ny D e sign Control Guidance Ele ments
6.2. Capture f requenc y and nature of e le me nt change s
6.2.1. Provide ra tionale for cha nge
6.2.2. D esc ribe dec isions m ade
6.2.3. Identif y approva l a uthority for the c hange
6.2.4. Capture da te , time , and signature of approving a uthority
6.3. Identify im pacted e lem ents due to a cha nge in another elem ent
6.3.1. Crea te backw ar d tr ace s to design elem ents w ithin and ac ross any organizational pr ocedure
6.3.2. Crea te backw ar d tr ace s to design elem ents w ithin and ac ross any projec t 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 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
User Reqts Technical Reqts Test CasesDesign
Traceability is the key to conformance and compliance
•Initial user requirements will be decomposed to more detailed
requirements, then to design, tests, etc.
•Decomposition creates traceability relationships
•Relationships define your traceability model
•Your traceability model is the basis for your process
•Enforce your traceability model; improve your process

37. Requirements in the V-Model

38. Requirements Tracing
•Individual requirements are traced
back from the software
specification to the system
requirements to the customer
requirements
•Sets of links “satisfy” the
requirement
•Identifies “orphan” requirements

39. Impact Analysis Through Traceability
•See effect of proposed change
immediately
•More effectively assess cost of
change
•Better visibility of potential risks to
implementing changes in
requirements

40. Why is Requirements Management So
Critical?
42%
37%
27%
26%
24%
24%
0%10%20%30%40%50%
Unclear or continually changing product
definitions
Product does not meet customer or market
requirements
Unrealistic schedule expectations
Projects not adequately staffed
Unclear or continually changing priorities
Unrealistic financial expectations
Source: AberdeenGroup, August 2006
Why do Products Fail?

41. What Happens Without
Requirements Management?
Clear business
objectives
17%
User
involvement
7%
Minimized scope
12%
Agile requirements process
Executive
support
14%
15%
14%
6%
5%
5%
5%
Experienced
Project Manager
Standard
infrastructure
Reliable
Estimates
Formal
methodology
Skilled Staff
Source: “Chaos Chronicles, III,
2003”. www.standishgroup.com
Approximately 60%-70% of IT project failures result from
poor requirements gathering, analysis, and management.
- Meta Group, March 2003
“If you do a post-mortem evaluation on unsuccessful software
projects, you'll find that most of them failed because the person
responsible didn't properly manage the project's requirements and
expectations.”
- Andy Feibus
RM challenges cannot be solved with a single point solution