Doors Slides

IBM Software Group | Rational software

Requirements Management withRational DOORS

• Requirement Management

• Introduction to DOORS

• Hands-on Training on DOORS

• Summary

• Q & A & Closing Comments

Agenda

Why Manage Requirements?

solve the right problembuild the right system

I distinctly said monorails! Did not!


Requirements-Driven Innovation through Automated LifecycleManagement


Who Uses DOORS?

Providers generate original requirementsBusiness analysts, product managers,requirements analysts, marketing

Reviewers provide feedback on deliverablesManagers, end users, QA,remote users, project managers

Requirements users generate most project dataSystems/software engineers,test engineers


How Do We Get Started?

The project already has a lot of documentation

How can this be used without needing to start again?

There are still a lot of requirements to write

Can they be written easily right in DOORS?

Printed documentation is very important

Is it necessary to spend time writing reports to get good documentation?


Import All Your Data & Create Documents

MS-Word

MS-Word

RTF

OLE

ASCII

Direct Entry

Microsoft

HTML

RTF

Word

PowerPoint

Excel

Outlook

MS-Word

Spreadsheet

MS-Project

Tool Integrations*

Interleaf

FrameMaker

DOORSASCII

Spreadsheet

MS-Project

Tool Integrations*

Interleaf

FrameMaker

Print

* See later Integrations slide


Getting started is easy in DOORS

Start with anoutline ortemplate

Simply typein yourrequirements


Is DOORS Easy to Use?

The project is already in progress

How long will it take to get everybody using DOORS?

People are used to Microsoft Word or Excel

Do users have to learn a totally new interface from the beginning?

Documents are easy to understand

Do we have to understand databases to use DOORS?


Microsoft Word import

Start in Word

Simply import into aDOORS document

Une!


DOORS Database View

Unlimited hierarchy supports scalability

Folders

Deleted Folder

iqu

Projects DOORS Documents

Organize Your Projects


DOORS Document Views

Simple document view of a database; get started quickly

See multiple requirements logically


DOORS views

Change bars and link indicators; instant traceability

See status quickly and concisely


DOORS views

Attribute columns in a spreadsheet-like view

Rich information; one window


Unlimited user defined attributes

Unlimited number of attributes in a spreadsheet-like viewValues can be calculated for metrics collectionAny value or attribute may be displayed in any column


Should Requirements be Text or Pictures?

We often find it easier to draw pictures than write text

Can we draw pictures in DOORS?

We want to refer to the pictures as requirements

Can we link directly to picture elements?

We’d like to formalize some of the pictures

Can we create formal UML diagrams as well as informal pictures?

Unique!


DOORS/AnalystIndustry-first UML 2.1 Visual Modeling Inside a Requirements Management Tool

Why not capture pictures with your requirements?

Put the pictures into your requirements specification

Easily view or print the requirements with embedded pictures

Create informal pictures or formal models based on UML 2


How Can I Manage Traceability?

We have never done traceability before

How much overhead is this going to add to a project?

We must have detailed reports of impact

How comprehensive are the traceability reports?

We need to see when requirements have been missed

Can we easily create queries to find “missing” links

We do incremental development with concurrent phases

How easy is it to keep traceability separate for each increment?

1.

activities1.1. Input electronically formatted data 1.1. Input electronically•Impact Reports: other design elements affected formatted dataThe plans shall

The plans

•Traceability Reports: Procedure AttributeThe2.2. Organize design elements plans shall be approved as design and development evolves. 2.2. Organize design elements2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element

2.3.1. Store design elements by Design Control Guidance Element 2.3.1. Store design elements by Design Control Guidance ElementGuidance Elementsand patient.2.3.2. Store design elements and their historical values 2.3.2. Store design elements and their historical values

2.

Manage all user needs 3. Manage all user needs

2.3.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.3.3. Identify the customer (s) 1.1.5.Create forward impacts to design elementscustomer and across any project milestone

2.7. The design inputGuidance Elements•Impact Reports: Linked design elements requirementsManage design input requirements 4. Manage design input

shall4.1. Identify the source of the requirement be documented. 4.1. Identify the source of the4.2. Identify the associated user need Questions.

•Link Change Design Object with affectedrequirementelement(s) and attributes4.3. Capture requirement description and attributesdesign input.

2.10.2. From what sources are design inputs sought?4.5. Assign responsibility for each requirement 4.5. Assign responsibility for each•Impact Links and Reports from affected design element(s)requirement1.2.1.Associate design element changes with decisions, rationale, and approval authoritylist additional aspects.)

2.10.3.1. intended use information2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safetyManage acceptance 5. Manage acceptance

2.10.3.5. limits and tolerances •Decision Attribute

2.10.3.7. toxicityelectromagnetic compatibility (EMC)

•Management Approval Attributecompatibility with accessories/auxiliary devices

2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging6.1.1. Make complete change history available 6.1.1. Make complete change history2.10.3.14. reliability2.10.3.15. statutory and

2.10.3.17.2.10.3.18. sterility6.2.1. Provide rationale for change

2.10.3.20.2.10.4. For the specific design

• Design Change Reports•

6.

3.

4.

5.

••

1.1. andIdentify impacted1. Capturewith and related elements

in, input 1.3.

The plans be “designdesign and

2.2.2. Organize by2. 820.30(c)1.1.3.relating to 2.3. Ensure all within and areacrossare Each

•toneeds of the

3.2. Identify all

3.5. State the2.6. The design3.6. Capture the within and for each user need

4.4.from affected design

Approve all Attributes:

input risk

input

6. Manage change6.1. Link on of design element

6.1.3. Link on within acrossacross any Control standards 6.1.4.Link on history and

6.2. across Design and nature of element changes6.2.1. Link traced change

6.2.3.Link to linked design for the1.3. Mange the

to a2.10.5. in another design •Design


Traceability is the key to compliance

User Reqts820.30(b) Design and Development Planning

Technical Reqts

1. 820.30(b) Design and Development Planning

Design Test CasesEach 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?

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

Initial user requirements will be decomposed to more detailedrequirements, 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


Traceability; drag-and-drop linking

Drag-and-dropto link within adocument . . .

. . . or fromdocument to

document

Une!

The plans

•Traceability Reports: Procedure AttributeThe2.2. Organize design elements plans shall be approved as design and development evolves. 2.2. Organize design elements2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element

and patient.2.3.2. Store design elements and their historical values 2.3.2. Store design elements and their historical values

3. Manage all user needs 3. Manage all user needs

•Impact Reports: ProcedureIdentify all user types (groups)3.2. Attribute3.2. Identify all user types (groups)

2.7. The design inputGuidance Elements

4. Manage design input

5. Manage acceptance

2.10.3.12. physical/chemical characteristics

2.10.3.14. reliability2.10.3.15. statutory and

2.10.3.17.

6.2.1. Provide rationale for change

2.10.3.20.2.10.4. For the specific design

• Design Change Reports•

••

The plans be “designdesign and

2.2.2. Organize by2. 820.30(c)relating to 2.3. Ensure all within andareacrossare Each

device are Guidanceand address of the user

•toneeds of the

3.3. Identify the within(s)1.1.5.3.5. State the2.6. The design

6.1.3. Link

1.3. Mange theto a2.10.5. in another design •Design


Traceability viewUser Reqts Technical Reqts Design Test Cases

iqu

End-to-end visual validation in a single view


Traceability verification or “completeness”

Increases customer confidence

Orphanreports& traceabilityreports show“missing”links


How Can I Manage Change?

Change can cause a project to exceed its budget

Can we control change?

Change can be very disruptive to those affected

Can we review changes before they are made rather than after?

Change must be traceable

Can we see where a change came from after it has been made?


DOORS’ Change Proposal System (CPS)E-mail

User submits“Change Proposal”

E-mail

Accepted

Collect changes from Changes reviewedall users including

DOORSneton-line Hold

On ReviewRejected

Manage change without surprises


How Can I Find Changes Easily?

Changes can happen overnight

Can DOORS tell me if a change affects my work?

Sometimes we need to look at older requirements

Can I see a history of each requirement?

Milestones are very important to project progress

Can we take a snapshot of the requirements at any milestone?


What are Suspect Links?

If documents are linked …

… a change bythis user here…

… shows up as awarning flag to thisuser here.

Une!


Suspect Links iqu

Suspect links are visible directly in the document as indicators or as a fulldescription

Never miss a change again


History and Baselines

ChangeHistory

PreviousBaseline

Current Version


Baseline Compare

Provides a concise list of differences as a single report


Microsoft Word export

DocumentTable

Book


Printing with standard layouts

Summary• Getting started is easy and supports different formats

to import • Unlimited hierarchy supportable and scalable tool• Manages Traceability• Unlimited user defined attributes supports• Manage Changes• History and Baselines the modules and compares of

Baselines• Helps to write test cases• Helps to export into different formats

Doors Slides

Documents

Transcript of Doors Slides