dynamic object-oriented requirements system (doors)
DESCRIPTION
TRANSCRIPT
Discussion Topics
• What is requirements management (RM)
• Who uses RM
• What is DOORS
• How do you use DOORS
• What is DOORS Web Access
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
®
So What Are Requirements?
Requirements
Obj
ectiv
eG
oalAim
Reg
ulat
ion
Criterion NeedFeat
ureFunction R
ule
Ris
k
Using DOORS in the RM market
Organization Type Drivers
Telecom equipment manufacturersTime to market and Compliance
Driven
• 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
Complex IT includingFinance and Telecom
Service ProvidersMarket and Quality 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
Military/Defense Contractor/Government
Contracts 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)
Aerospace, Automotive, and Medical Instrumentation
Compliance 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
Source: The Seattle Times
Boeing 787: # of engineers are 2005 projections and may not include all engineering specialties. Production workers are not included.
Bo
ein
g 7
87 D
ream
lin
er
Number of parts: 6 millionPeak 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,000Design changes per year: 150,000
Customers examples…
DXL scripting
Data Exchange
Access Control
Roles
Configuration
ProductComponents
DOORS
Dynamic Object Oriented Requirements System
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
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
Client/Server Architecture (Simplified)
DOORSData
DDBS
Windows / Unix
Directory Tree
DOORS
Web
Access
DOORSon Windows
TCP/IP
Local filesystem
Windows Service /
UnixProcess
TCP/IP
WebBrowser
TCP/IPTCP/IP
DOORS
App. Server
TCP/IP Client
Typical Network Installation
Configuring the registry and using command-line switches
for the Rational DOORS client
• Registry settingsWhen you start Rational DOORS on a Windows computer, it uses
the default configuration information in the registry.
DOORS directories
Configuring the registry and using command-line switches
for the Rational DOORS client
• Starting Rational DOORS from a shortcutOn Microsoft Windows® computers, you can use a shortcut to run Rational DOORS.
• Command-line switches for the Rational DOORS clientYou can use command-line switches to override the registry settings when the Rational DOORS starts.
• 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
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
• Database• Projects and Folders• Modules
Views
Attribute
Links
DOORS Architecture
DOORS Architecture - Modules• Modules contain a hierarchy of objects
• Objects contain attribute values
• Objects can be linked
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
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
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 haveare ofhave
Items Access Rights Users User Types Powers
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
DOORS Web Access: Architecture
DWA Server
DWA Broker
Interop Server Cluster
Interop Server Cluster
Interop Server Cluster
TCP
TCP
DOORS Database
TCP
Flex LMTCP
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
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
Using DXL (the Rational DOORS Extension Language)
• Setting up DXL securityYou 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 libraryThe 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 programsYou can use the DXL Interaction window to develop small DXL programs.
Roadmap DOORS and DOORS Web Access
September 2010: DOORS 9.3RTC, ClearQuest, Change integrations using OSLC-RM and OSLC-CM Embedded document generation with common reporting componentsAdditional translations: German, French, and RussianSSL communication with certificate based authentication (PKI)
September 2010: DOORS Web Access 1.4Enhanced filtering for improved analysis/reviewUI harmonization with IBM Rational Jazz clients
Q4 2010: DOORS Enterprise Technology PreviewCommon Jazz based requirement serverCOTS database
2009 2010 2011+
Backup material
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
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
ModelingTools
Simulation
Tools
CodingTools
TestingTools
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
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.
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
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
Traceability
• How requirements are satisfied
• How requirements are tested
• The impact of changing requirements
• The impact of test failure
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
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
Requirements in the V-Model
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
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
Why is Requirements Management So Critical?
42%
37%
27%
26%
24%
24%
0% 10% 20% 30% 40% 50%
Unclear or continually changing productdefinitions
Product does not meet customer or marketrequirements
Unrealistic schedule expectations
Projects not adequately staffed
Unclear or continually changing priorities
Unrealistic financial expectations
Source: AberdeenGroup, August 2006
Why do Products Fail?
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 EstimatesFormal
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