Sie sind auf Seite 1von 94

Getting the most out of DOORS for requirements management

Software Technology Center, BLAT


Vassilka Kirova & Darshak Kothari

October, 2004 Telelogic - Bell-Labs - NJIT

Outline
Overview of DOORS
Introduction Key concepts and elements Using DOORS

DOORS & Artifact Flow Through Demo

DOORS - Introduction

Telelogic - Bell-Labs - NJIT

DOORS ERS Architecture

Requirements Engineering & DOORS


Effectively generating High Quality Requirements: correct modifiable non-ambiguous consistent traceable understandable complete verifiable annotated

Requirements Engineering

Requirements Development
Elicitation Analysis Modeling & Specification Verification & Validation

Requirements Management
Change Control Version Control Tracing & Impact Analysis Status Tracking

Best Practices, Methods,Tools and Processes for Requirements Engineering

Key challenges
Communicate requirements to all project stakeholders to keep everyone on the same page Control changes to requirements, assess impact of proposed changes, and communicate approved changes Analyze requirements coverage to ensure customer satisfaction or compliance to regulations/contracts

Validate requirements early in system/software lifecycle to avoid costly redesign later


Design and implement system/software directly from a validated requirements-based model to ensure the right system is built

Communicate design to all project stakeholders

Impact of Requirements Problems?


As much as a 200:1 cost savings results from finding errors in the requirements stage versus finding errors in the maintenance stage of the software life-cycle.

Barry Boehm76, 88

56% of all bugs can be traced to errors made during the requirements stage

A Simple Project Model


User requirements Functional requirements Design specifications

Satisfies

Satisfies

Tests

Tests

Acceptance tests
8

Tests

Standards

Functional tests

Unit tests

DOORS - Key Concepts & Elements

Telelogic - Bell-Labs - NJIT

DOORS Database Explorer - Database View


Database

Projects

Documents Folders DOORS Database Explorer: Allows you to organize your data in the same way that you might organize it in MS Windows Explorer > explorer type navigation

10

The DOORS Explorer Project View


Only shows projects which you can access

11

Using Projects and Folders

Use a Folder to:


Creating structure and organization

Use a Project to:


Organize data related for a specific project or product

12

Documents in DOORS are referred to as Formal Modules or simply Modules


A module is a container for information (requirements, graphics, etc.)
Typically structured as a document
May be structured as a data file

13

Default Document Display

On the Left: Module Explorer allows you to navigate and see the structure
Right hand pane shows Heading and Text in a Document-Centric Format the way youre used to
14

Objects
Documents (or Formal Modules) are collections of Objects Objects may be used for
Requirement text Headings Graphics Any other information

15

Objects Have Properties


Detailed information about an object
1. General Heading, Short Text, Object Text values for the object 2. Access View or set access rights 3. History log of changes to the object 4. Attributes attribute values for the object 5. Links relationships to other objects

Right click on the object and select Properties


16

Object Structure Terminology


D
B E A C F H Structure as a Family: parent object A has children objects B and C child objects D and E have B as their parent siblings objects G and H have the same parent Structure as a Tree: leaf objects D, E, G, and H have no children non-leaf objects A, B, C, and F are parent objects
17

What is an Attribute?
Attributes are additional defined characteristics of a requirement; they provide essential information in addition to requirement text
Source Priority Verifiability Accepted Who specified this requirement? What is the priority of this requirement? Is the requirement verifiable? Has this requirement been accepted by the developers?

Review
Safety Comments Questions

Review status of this requirement


Is this a safety-critical requirement? Any comments on the requirement to clarify its meaning Any questions that must be clarified with the source

You can define attributes that will support your process and make your database more productive for you

What Attributes should you use?


18

Attribute Have:
Attribute Name Type

Access Definition

Default Value

Change Characteristics

19

Attributes can be assigned to: Documents (Modules), Objects (Requirements), and links

Object Attributes
Attributes allow additional information to be associated with each requirement

20

Attributes can also be defined for Documents (Modules) and Links

Filters

Filters allow you to reduce the information in the display to an essential set that interest you
Filters support your analysis of the requirements
21

Filters are used to:


Limit the display to visualize specific information
High Risk Requirements Requirements in Build 3.0 Requirements assigned to a specific individual Requirements that failed test

Set a specific value of an attribute to many objects at once.


You may want to set all requirements that have the word safe in them to Priority = High

Filters are saved when you save the View Views are Dynamic Reports of your Data
22

Views

Saving a View View Drop-Down Menu

Views define the layout of your data Columns, filters, sorts, window position, etc. Drop-Down list on left side of tool bar for easy access to your views Defaults for Users or Documents can be set
23

Using Views

Views can be used to


Save filter or sorting conditions

Save a display that contains attribute


Save a display that contains traceability Save a display that contains information of specific interest to certain users (e.g., managers, test engineers, reviewers, coders) Save window positions to facilitate linking

24

Links in DOORS
A relationship between two requirements (objects) is established using a link

Links can be followed in either direction


Bi-directional 1 to 1, 1 to n, n to 1, & n to n are supported

From (Source)
25

To (Target)

Using DOORS

Telelogic - Bell-Labs - NJIT

View requirements in context

Familiarity of document view; power of a database


27

Edit and baseline

28

Sharable Mode Operation: Defining Shareable Sections


Shareable Edit is based on Sections Sections are defined in the Exclusive Edit mode

29

Prioritizing, categorizing, or assigning requirements Annotate


requirements with an unlimited set of user-defined attributes Standard NOS template

Analyze requirements through multiple views


30

Tracking changes

Change History

Previous Baseline

Current Version
31

Including all stakeholders in the review process


Web browser interface
Global access Easy to use Common user interface No training required

Support for:
Distributed teams Requirements reviews Managers

32

Native requirements change control


Discuss required changes Notify users (e-mail, suspect links)

?
User submits Change Proposal

Anyone on the team can participate


Changes from all users including DOORSNet TM Changes reviewed on-line or in formal CCB
33

E-mail

Integrated Change Management - CPS


Discuss required changes
Notify users (e-mail, suspect links)

Read-only user submits Change Proposal Notify users (e-mail)

Change Proposal System


Changes from all users Changes reviewed on-line

34

Assess and discuss impact of changes

Linking & Traceability


For Traceability Automation see AFT

Drag-and-drop to link within a document . . . . . . or from document to document.

or across projects.
35

Establish traceability from tests to requirements


User requirements Functional requirements Design specifications

Satisfies

Satisfies

Tests

Tests

Acceptance tests
36

Tests

Standards

Functional tests

Unit tests

Use traceability to perform analysis


Coverage analysis Impact analysis Derivation analysis

37

Coverage Analysis
User requirements Functional requirements Design specifications

% Complete ?

Satisfies

Satisfies

Tests

Tests

Acceptance tests

Tests
38

Standards

Functional tests

Unit tests

Coverage Analysis
User requirements Functional requirements Design specifications

Gold plating ?

Satisfies

Satisfies

Tests

Tests

Acceptance tests

Tests
39

Standards

Functional tests

Unit tests

Analyzing Impact
User requirements Functional requirements Design specifications

What if ?

Satisfies

Satisfies

Tests

Tests

Acceptance tests

Tests
40

Standards

Functional tests

Unit tests

Understand the impact of change before you introduce it


Navigation via link indicators

Explorer-style link navigation


Traceability matrix view

41

Derivation analysis
Why is ?
User requirements Functional requirements Design specifications

Satisfies

Satisfies

Tests

Tests

Acceptance tests

Tests
42

Standards

Functional tests

Unit tests

Impact/derivation analysis
User Reqts
1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, 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 Input 2.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 user and patient. 2.2. Each manufacturer shall maintain 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 user and 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 of design 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 use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.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?

Technical Reqts
2.

Design
1.1.1. Create backward traces to design elements within and across any organizational

Test Cases
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 and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design and development 1.1. Identify impacted elements due to a change in another element activities and define responsibility for implementation. 1. Capture design and related information 1. Capture design and related information with driving design elements Traceability Reports: consistency 1.1. Input electronically formatted data 1.1. Input electronically Impact Reports: other design elements affected formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, or result 1.2. Reference external information sources 1.2. Reference external information sources Links to impacted design elements in, input to the design and development process. 1.3. Reference external documentation 1.3. Reference external documentation

3.

4.

5.

6.

The plans shall be reviewed as design and development evolves. Store design and related information 2. Store design and related information procedure The plans shall be updated as design and development evolves. 2.1. Identify and tag design information as unique design elements 2.1. Identify and tag design information as unique design elements Attribute Traceability Reports: Procedure The plans shall be approved as design and development evolves. 2.2. Organize design elements 2.2. Organize design elements 1.1.2. Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2. 820.30(c) Design Input Attribute Traceability Reports: Milestone 2.2.2. Organize by inter-relationships 2.2.2. Organize by inter-relationships 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to backward a 1.1.3. Create traces to design elements within and are across Design Control 2.3. Ensure all design elements are available 2.3. Ensure all design elements available device are appropriate address the intended use of the device, including the needs of the user 2.3.1. Store design elements by Design Control Guidance and Element 2.3.1. Store design elements by Design Control Guidance Element Guidance Elements andhistorical patient. values 2.3.2. Store design elements and their 2.3.2. Store design elements and their historical values Reports: Linked design elements Traceability 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a forward impacts to design within and across any organizational device are appropriate and address the intended use of the device, including the1.1.4. needs Create of the user Manage all user needs 3. Manage elements all user needs and patient. procedure 3.1. Identify the source of the user need 3.1. Identify the source of the user need 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 3.2. Identify all user types (groups) 3.2. Identify all user types (groups) Attribute Impact Reports: Procedure 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer (s) 3.3. Identify the customer 1.1.5. Create forward impacts to design elements within(s) and across any project milestone 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients Attribute Impact Reports: Milestone The design input requirements shall be documented by a designated individual(s). 3.5. State the intended use of the 2.6. product (family) 3.5. State the intended use of the product (family) 2.7. The design input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and across Design Control 3.6. Capture the acceptance criteria for each user need 3.6. Capture the acceptance criteria for each user need 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, Manage design input requirements 4. Manage design input requirements design elements Impact Reports: Linked shall be documented. 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement 1.2. Associate changed design elements with related elements 2.10. Questions. 4.2. Identify the associated user need 4.2. Identify the associated user need 2.10.1. Summarize the manufacturer's written procedure(s) for identification and Linkof Change Design Object 4.3. withCapture affected design element(s) control 4.3. Capture requirement description and attributes requirement description and attributes design input. 4.4. Capture acceptance criteria 4.4. from Capture acceptance criteria affected design element(s) Traceability Links and Reports 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 4.5. affected Assign responsibility for each requirement design element(s) Impact Links and Reports from 4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and 4.6. Manage incomplete requirements 1.2.1. Associate design element changes with decisions, rationale, and approval authority list additional aspects.) 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements information 2.10.3.1. intended use 4.8. Manage conflicting requirements 4.8. Manage conflicting requirements 2.10.3.2. user/patient/clinical with following Attributes: 4.9. Approve all requirements 4.9. Approve all requirements Change Decision Objects 2.10.3.3. performance characteristics Disposition Attribute 2.10.3.4. safety Manage acceptance 5. Manage acceptance Decision Attribute 2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 5.1. Ensure the acceptance of every user need 2.10.3.6. risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.2. Ensure the acceptance of every design input requirement 2.10.3.7. toxicity and biocompatibility 5.3. Document the results of every user need acceptance test 5.3. Document the results of every user need acceptance test Owner Attribute electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. input requirements test 5.4. Document the results of every design input requirements test Management Approval Attribute 2.10.3.9. compatibility with accessories/auxiliary devices 5.5. Make acceptance results available 5.5. Make acceptance results available 1.2.2. Provide associations within and across any organizational procedure 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors Link on Procedure Attribute Change Design Object Manage change 6. Traceability Manage change 2.10.3.12. physical/chemical characteristics 6.1. Maintain history of design element changes 6.1. Maintain of design Attribute element changes Link history on Procedure Change Design Object Impacts 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.1. Make complete change history available 1.2.3. Provide associations within and across any project milestone 2.10.3.14. reliabilityprocedure 6.1.2. Maintain history within and across any organizational 6.1.2. Maintain history within and across any organizational procedure Link on Milestone Attribute Change Design Object Traceability 2.10.3.15. statutory and regulatory requirements 6.1.3. Maintain history within and across any project milestone 6.1.3. Maintain history within and across any project milestone 2.10.3.16. voluntary standards Change Design Object Impacts Link on Milestone Attribute 6.1.4. Maintain history within and across any Design Control Guidance Elements 6.1.4. Maintain history within and across any Design Control Guidance Elements 2.10.3.17. 6.2. Capture frequency and nature of element changes manufacturing processes 6.2. Capture frequency natureGuidance of element changes 1.2.4. Provide associations within and across Design and Control Elements 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.1. Provide fordesign change elements Linkrationale to traced Change Design Object Traceability 2.10.3.19. MDRs/complaints/failures and other historical data 6.2.2. Describe decisions made 6.2.2. Describe decisions made Link to linked design elements Change Design Object Impacts 2.10.3.20. design history files (DHFs) 6.2.3. Identify approval authority for the change 6.2.3. Identify approval authority for the change 2.10.4. For the specific design covered, how were the design input requirements identified? 1.3. Mange the change process 6.2.4. Capture date, time, and signature of approving authority 6.2.4. Capture date, time, and signature of approving authority 2.10.5. For specific design covered, how were the design input requirements reviewed forChange Module 6.3. Identify impacted elements due to a change in the another element 6.3. Identify impacted elements due to a change in another element Design adequacy? 6.3.1. Create backward traces to design elements within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone

Object History Object History Reports Versions Baselines

43

End-to-end visual validation in a single view


User Reqts Spec
1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, 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 Input 2.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 user and patient. 2.2. Each manufacturer shall maintain 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 user and 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 of design 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 use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.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?

Functional Spec
2.

Design Spec

Test Cases

1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design and development 1.1. Identify impacted elements due to a change in another element activities and define responsibility for implementation. 1. Capture design and related information 1. Capture design and related information with driving design elements Traceability Reports: consistency 1.1. Input electronically formatted data 1.1. Input electronically Impact Reports: other design elements affected formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, or result 1.2. Reference external information sources 1.2. Reference external information sources Links to impacted design elements in, input to the design and development process. 1.3. Reference external documentation 1.3. Reference external documentation

3.

4.

5.

6.

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 1.1.1. Create backward traces to design elements within and across any organizational The plans shall be reviewed as design and development evolves. Store design and related information 2. Store design and related information procedure procedure The plans shall be updated as design and development evolves. 2.1. Identify and tag design information as unique design elements 2.1. Identify and tag design information as unique design elements Attribute Traceability Reports: Procedure Traceability Reports: Procedure Attribute The plans shall be approved as design and development evolves. 2.2. Organize design elements 2.2. Organize design elements 1.1.2. Create backward traces to design elements within and across any project milestone 1.1.2. Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2. 820.30(c) Design Input Attribute Traceability Reports: Milestone Traceability Reports: Milestone Attribute 2.2.2. Organize by inter-relationships 2.2.2. Organize by inter-relationships 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to backward a 1.1.3. Create traces to design elements within and are across Design Control 2.3. Ensure all design elements are available 2.3. Ensure all design elements available 1.1.3. Create backward traces to design elements within and across Design Control device are appropriate address the intended use of the device, including the needs Guidance of the user Elements 2.3.1. Store design elements by Design Control Guidance and Element 2.3.1. Store design elements by Design Control Guidance Element Guidance Elements andhistorical patient. values 2.3.2. Store design elements and their 2.3.2. Store design elements and their historical values Reports: Linked design elements Traceability Traceability Reports: Linked design elements 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a forward impacts to design within and across any organizational 1.1.4. Create forward impacts to design elements within and across any organizational device are appropriate and address the intended use of the device, including the1.1.4. needs Create of the user Manage all user needs 3. Manage elements all user needs and patient. procedure procedure 3.1. Identify the source of the user need 3.1. Identify the source of the user need 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 3.2. Identify all user types (groups) 3.2. Identify all user types (groups) Attribute Impact Reports: Procedure Impact Reports: Procedure Attribute 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer (s) 3.3. Identify the customer 1.1.5. Create forward impacts to design elements within(s) and across any project milestone 1.1.5. Create forward impacts to design elements within and across any project milestone 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients Attribute Impact Reports: Milestone Impact Reports: Milestone Attribute The design input requirements shall be documented by a designated individual(s). 3.5. State the intended use of the 2.6. product (family) 3.5. State the intended use of the product (family) 2.7. design input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and across Design Control 1.1.6. Create forward impacts to design elements within and across Design Control 3.6. Capture the acceptance criteria forThe each user need 3.6. Capture the acceptance criteria for each user need 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements Guidance Elements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, Manage design input requirements 4. Manage design input requirements design elements Impact Reports: Linked Impact Reports: Linked design elements shall be documented. 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement 1.2. Associate changed design elements with related elements 1.2. Associate changed design elements with related elements 2.10. Questions. 4.2. Identify the associated user need 4.2. Identify the associated user need Linkof Change Design Object 4.3. withCapture affected design element(s) 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control Link Change Design Object with affected design element(s) 4.3. Capture requirement description and attributes requirement description and attributes design input. 4.4. Capture acceptance criteria 4.4. from Capture acceptance criteria affected design element(s) Traceability Links and Reports Traceability Links and Reports from affected design element(s) 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 4.5. affected Assign responsibility for each requirement design element(s) Impact Links and Reports from Impact Links and Reports from affected design element(s) 4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and 4.6. Manage incomplete requirements 1.2.1. Associate design element changes with decisions, rationale, and approval authority 1.2.1. Associate design element changes with decisions, rationale, and approval authority list additional aspects.) 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements information information 2.10.3.1. intended use 4.8. Manage conflicting requirements 4.8. Manage conflicting requirements 2.10.3.2. user/patient/clinical with following Attributes: 4.9. Approve all requirements 4.9. Approve all requirements Change Decision Objects Change Decision Objects with following Attributes: 2.10.3.3. performance characteristics Disposition Attribute Disposition Attribute 2.10.3.4. safety Manage acceptance 5. Manage acceptance Decision Attribute Decision Attribute 2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 5.1. Ensure the acceptance of every user need 2.10.3.6. risk analysis Rationale Attribute Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.2. Ensure the acceptance of every design input requirement 2.10.3.7. toxicity 5.3. Document the results of every user need acceptance test and biocompatibility 5.3. Document the results of every user need acceptance test Owner Attribute Owner Attribute electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. input requirements test 5.4. Document the results of every design input requirements test Management Approval Attribute Management Approval Attribute compatibility with accessories/auxiliary devices 5.5. Make acceptance results available 2.10.3.9. 5.5. Make acceptance results available 1.2.2. Provide associations within and across any organizational procedure 1.2.2. Provide associations within and across any organizational procedure 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors Link on Procedure Attribute Change Design Object Change Design Object Traceability Link on Procedure Attribute 6. Traceability Manage change Manage change 2.10.3.12. physical/chemical characteristics 6.1. Maintain of design Attribute element changes 6.1. Maintain history of design element changes Link history on Procedure Change Design Object Impacts Change Design Object Impacts Link on Procedure Attribute 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.1. Make complete change history available 1.2.3. Provide associations within and across any project milestone 1.2.3. Provide associations within and across any project milestone 2.10.3.14. reliabilityprocedure 6.1.2. Maintain history within and across any organizational procedure 6.1.2. Maintain history within and across any organizational Link on Milestone Attribute Change Design Object Traceability Change Design Object Traceability Link on Milestone Attribute 2.10.3.15. statutory and regulatory requirements 6.1.3. Maintain history within and across any project milestone 6.1.3. Maintain history within and across any project milestone 2.10.3.16. voluntary Link on Milestone Attribute Change Design Object Impacts Change Design Object Impacts Link on Milestone Attribute 6.1.4. Maintain history within and across any Design Control Guidance Elements 6.1.4. Maintain history within and across any Design Control standards Guidance Elements 2.10.3.17. 6.2. Capture frequency natureGuidance of element changes 6.2. Capture frequency and nature of element changes manufacturing processes 1.2.4. Provide associations within and across Design and Control Elements 1.2.4. Provide associations within and across Design Control Guidance Elements 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.1. Provide rationale for change Change Design Object Traceability Link to traced design elements Change Design Object Traceability Link to traced design elements 2.10.3.19. MDRs/complaints/failures and other historical data 6.2.2. Describe decisions made 6.2.2. Describe decisions made Change Design Object Impacts Link to linked design elements Change Design Object Impacts Link to linked design elements 2.10.3.20. design history files (DHFs) 6.2.3. Identify approval authority for the change 6.2.3. Identify approval authority for the change 2.10.4. For the specific design covered, how were the design input requirements identified? 1.3. Mange the change process 1.3. Mange the change process 6.2.4. Capture date, time, and signature of approving authority 6.2.4. Capture date, time, and signature of approving authority 2.10.5. For specific design covered, how were the design input requirements reviewed forChange Module 6.3. Identify impacted elements due to a change in another element 6.3. Identify impacted elements due to a change in the another element Design Design Change Module adequacy? 6.3.1. Create backward traces to design elements within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone Object History Object History Object History Reports Object History Reports Versions Versions Baselines Baselines

We need to demonstrate compliance with our customers requirements

44

Ensure all requirements have been satisfied


Standard views and reports show missing links

Filters quickly identify unmet requirements

Increases customer confidence


45

OLE Support
DOORS provides OLE support on Windows
You can embed an OLE object Use edit-in-place to make changes after embedded
You can link an OLE object Changes are made to the file in its original location Embed or link in a DOORS object: Table, Spreadsheet, Equation, Chart/graph Picture, Audio clip, Video clip The choice is only limited by what is installed on your system

46

OLE Link or Embedding


Select insertion point in module Insert / OLE object
Create New Select type Create from File Browse to select Link or embedd

Double-click
Launches source application

Maintain as any DOORS object


Move, Copy Attributes Link
47

Export from Word to DOORS


Initiate from Word Export to current Project or Folder in DOORS

48

Incorporating existing documentation

MS-Word
MS-Word

RTF OLE ASCII

Automate d import

Spreadsheet

Interleaf
FrameMaker

Migrating existing project information to DOORS


49

Publishing and Report Generation


Printer Word Microsoft PowerPoint Excel Outlook
MS-Word

Automated report generation from any view

HTML
RTF ASCII Spreadsheet Interleaf FrameMaker

Publish reports with the required content and format


50

Printing Documents Directly from DOORS


Documents can be printed directly from DOORS The current view is printed (WYSIWYG)
All objects in the current view All attributes currently displayed

Page Layouts can be created and saved Reports combine Views and Page Layouts

51

Print Preview

52

Requirements in the lifecycle


Requirements Capture & Engineering

Analysis & Design Tools

Modeling Tools

Simulation Tools

Coding Tools

Testing Tools

Requirements Management & Traceability Tools

Documentation Tools
Project Management Tools

Configuration/Change Management Tools

Metrics Tools

53

DOORS is for more than just requirements

Lifecycle traceability
Business Process Modeling CM & Defect Tracking CASEwise (Corporate Modeler), Popkin (System Architect) Telelogic (Synergy), Merant (PVCS VM, Dimensions), Rational (ClearCase & ClearQuest), Intasoft (AllChange) Distributive SW (MetricCenter), Predicate Logic (TycoMetrics) Microsoft (MS Project), Primavera (Primavera Enterprise) Telelogic (Tau SDL Suite), Rational (Rose RT) , Artisan (Real-time Studio), ILogix (Rhapsody)

Metrics & Measurement Project Management Real-time Software Modeling

Software Modeling

Telelogic (Tau UML Suite), Rational (Rose), CA (Paradigm Plus), Embarcadero (GDPro), Togethersoft (TogetherJ), Aonix (Software Through Pictures)
Telelogic (Tau TTCN Suite), Mercury (TestDirector), Compuware (QA Director), T-Plan (T-Plan), Verecomm (TestExpert) Mathworks (MatLab), I-Logix (StateMate), Foresight Systems (Foresight), Virtual Prototypes (VAPS) Parametric Technology (WindChill), MatrixOne (eMatrix), IBM (Enovia), SDRC (Metaphase) Strategic Thought (Active Risk Manager) Galorath (SEER)

Software Testing

Systems Modeling & Simulation

PDM/E-PLM

Risk Management Cost Estimation

54

DOORS Integration in Lucent


Artifact Flow Through Environment (AFT)
DOORS as a component of AFT

Telelogic - Bell-Labs - NJIT

AFT is the Result of an Ongoing PacketIN & STC Collaboration


Goal
Increase quality and productivity

Decrease development cycle

Constraints
No impact on schedules Compliance with Mobility - AMPS/PCS process Compliance with TL 9000 requirements Use of Mobility standard tools

Engagement Model: Collaboration & Co-ownership Spirit of Continuous Improvement with Clear Targets Focus on Technical Excellence
56

What is Artifact Flow Through?


A Modular, Integrated Method, Tool and Process Environment for:
Specification, modeling, generation and management of software artifacts requirements, designs, and test work items Process improvement supporting collaboration, elimination of functional smokestacks, and more iterative development
PacketIN Environment
Design to Req. Traceability

Extended Developer Support


ROSE

Extended System Engineering Support


DOORS

Jumpstart Rose Model Generate Test Cases

Test Management
Req. to Test Traceability

Leverages best software practices


Use case driven, scenario-based development Model-based design Early testing paradigm

Tester Activities

APX-TMS

PacketIN Targets

Success Criteria
Reduction in Effort (THCM) Reduction in defects (end customer) Increase in multi-use of artifacts Increase in degree of automation

Target (per release)


13%-20% 20% 10% 30%

Data-driven approach
Metrics definition and automation Benchmarking data & monitoring Data collection, analysis and ongoingimprovement
57

The Best Practices Effect: Early Defect Prevention & Reduction


Current
Rate of Discovery

Proposed

Defect Prevention & Reduction

Requirements

Design & Build

Release to Test TIME

Release to Field

Source*: Boehm, Barry. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, Inc. 1981. Boehm, Basili. Software Management. IEEE Computer, January 2001. 58

AFT: Benefits
AFT Increases quality and productivity while reducing the cycle time via:
Common scenario-based representation throughout development cycle
Cumulative $

PacketIN Projected Gain


Cumulative ROI
2,000,000 1,500,000 1,000,000 500,000 0 Sept '02 (500,000) Time Sept '03 Sept '04 Cumulative Savings Cumulative Cost Estimate Cumulative ROI

Smooth handoffs of artifacts artifact flow with no-rework


Maximum reuse of knowledge and artifacts Maximum automation generation of test cases, design jumpstart, metrics Automated Traceability
59

Projected ROI
$200-500K in the first year $1-2M in each subsequent year
Distribution of savings: Reduction in field defects accounts for 35% of the expected savings Effort reduction accounts for 65% of the expected savings

AFT: Key Components & Features


FTF 010 Rose - based Design FTF 009 CM (CCMS) for Rose Models FTF 018 Design to UT Traceability

FTF 005 Design to Req. Traceability

Developer Activities
FTF 002 SRD support in DOORS DOORS 001 DOORS Infrastructure DOORS 003 XML Generation FTF 006 Use Case Syntax Check

ROSE

XML Representation of Requirements

FTF 008 Rose Model Jumpstart FTF 007 Test Case Generation

SE Activities

DOORS

Test Management
FTF 004 Req. to Test Traceability

Tester Activities

APX-TMS

60

End-to-End Workflow: Flowthrough


DOORS
Create SRD UCs, POTR Import DXL SE XML & MS Word Files Hand-off COMPAS Hand-off PDF/MS Word File COMPAS/LiveLink Generate XML & Supporting MS Word File Generate PDF and MS Doc
Generate for review, send notification Generate baselined version, send notification

Jumpstart Rose Model

Generate & Store Test Case

Developer Create Design Models

D-INTA

T-INTA

Tester

Manage Test Cases

ROSE
Rose Model Hand-off CCMS Publ. Model Hand-off WEB

TMS

Design Document - COMPAS

61

Better Requirements and Product Quality through Use Cases (UC)


Characteristics and Benefits
UCs capture a contract between the stakeholders of a system about its behavior UCs specify systems behavior under various conditions (success & failure modes) in a way that is concise and easy to understand, track, and validate UCs are collections of scenarios; scenarios provide context traditional requirements are often too ambiguous UCs are a key to the creation/ generation of quality test cases and system verification
62

Industry data:

Use cases improved developer productivity by 40% (DaimlerChrysler) 35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases

End to End Workflow: Traceability

FTF 004
Generate XML: UC, POTR, Links Querying TMS Data Generate/ Update Surrog. Module Auto-Generate DOORS-TMS Links

SE

DOORS

DXL

XML File

TMS Data File

Populate ReqLink Property, ReqList Package

Developer
Models Annotated with Req.; Run a Report Models Annotated with Tests; Run a Report

Tester ROSE TMS Query Support TMS

Traceability Report

63

Innovate the Way The Team Works Together: Process Flow for High Quality
Requirements written in DOORS Early Comments to SE
High Quality Review

Delivered to tester (and developers) early

Initial run through INTA


64

AFT Software Innovation


Integrated Best Practices, Processes & Tools System Engineering
(Extending DOORS)
Support for Use Cases in DOORS
Structured template Syntax Checker

Design
(Augmenting Rose)

Test
(Augmenting TMS)

XML representation of requirements for downstream tools Test coverage reports (traceability support) Metrics Reports

Test cases generation Design model jumpstart from requirements tool use case view and Optimized coverage UML sequence diagrams Choice of algorithms Design-to-unit test traceability support Tool-based requirements traceability Design to requirements Gaps & coverage traceability tool and Change notification reports Impact analysis Guidelines for legacy code Test reuse reengineering

Adds functionality to standard Mobility tools Provides Glue Software Scalable integration architecture
66

Summary
DOORS & AFT provide the ability to

Capture, manage, and communicate requirements and their changes Support the approval process of changes Verify requirements early in the lifecycle

Generate test cases from requirements


Automate traceability of requirements Ensure requirements are met/addressed

67

Demo
FTF 010 Rose - based Design FTF 009 CM (CCMS) for Rose Models FTF 018 Design to UT Traceability

FTF 005 Design to Req. Traceability

Developer Activities
FTF 002 SRD support in DOORS Demo DOORS 001 DOORS Infrastructure DOORS 003 XML Generation FTF 006 Use Case Syntax Check

ROSE

SE Activities

Demo

XML Representation of Requirements

FTF 008 Rose Model Jumpstart FTF 007 Test Case Generation Demo

DOORS
Demo

Test Management
Tester Activities

FTF 004 Req. to Test Traceability

APX-TMS

68

QUESTIONS? COMMENTS?

Telelogic - Bell-Labs - NJIT

Backup

Telelogic - Bell-Labs - NJIT

Requirements are stored in DOORS

Demo

Telelogic - Bell-Labs - NJIT

Use Cases in DOORS

72

Structured Representation of Use Cases

73

More on Use Cases

74

Use Cases and POTR can be Linked

75

Some POTR are Linked with Use Cases

76

DOORS Extensions

77

Backup AFT

Telelogic - Bell-Labs - NJIT

Test Framework Generation


The Test Framework is created from requirements-level scenarios:
source: the Use Cases in DOORS
step 1: extract into an XML file: main scenario plus alternative scenarios (based on the Extensions and Variations)
The XML file is a representation of all of the possible paths through a use case (successes and failures) The example has two possible paths: 1,2,3,Success and 1,2,3,3a,3a1,Failure Each path can be a separate test case
3a. System cant set .. 3a1. System displays error message

Start
1. System prompts user for 2. User enters 3. System sets

Fail

Success

79

More Test Framework Generation


Converting XML to test templates
step 2: using the IN-TA tool (on Windows):

user loads the XML file,


IN-TA tool prompts with all possible scenarios for each use case, test engineer selects the use cases and the scenarios within the use cases to import as TMS test cases.

Which paths will the IN-TA tool display to the user?


combinatorial explosion if there are many extensions and variations

80

Test case generation options


Main + Var + Ext is the default method
it takes the main (sunny day) path through the scenario and adds a path for each of the variation and each extension to that path this is the best option for most situations

All Steps (Nodes)


this method picks the least (approximately) number of paths that will visit all the steps in the scenario (nodes in the graph)

All Transitions (Links)


this method picks the least (approximately) number of paths that will traverse all of the transitions between the steps (links in the graph)

All Unique Paths


this method picks every unique way (exhaustive) to go through the scenario

81

Which option?
If all branches never rejoin, then all of these generation options are equivalent If some Extensions rejoin the main scenario, then All Steps might yield a smaller number of complex scenarios All Transitions guarantees exhaustive coverage of nodes and links

4 scenarios cover all of the nodes and edges

Main+Var+Ext = 4 All Steps = 2

Success

Failure

It doesnt matter which option you choose

Do you want simple tests? Do you want to minimize the number of tests?

82

Use Case Time Savings


Manual
Read requirements, try to understand all combinations Build all combinations by hand Generate Oneliners Wait for cron job

INTA
Read requirements generate all combinations Tools generates all possible combinations with all header info Fill in details

Fill in Header info


Fill in details How long does this take you? Only time for details!

83

POTR Time Savings


Manual INTA

Read requirements. Generate Oneliners Wait for cron job Fill in Header info Fill in details

Read Requirements. Tools generates test for all POTR and fills in the header information. Fill in details Clone new tests Delete tests for <non testable requirements>

Do you get all POTR requirements? Do you need to add tests not related to requirements?

Time to Add NEW TESTS

Note: The cells on the left and right are step comparison. In the manual step a person needs to worry if they have created a test from all requirements. Using the tool, a one-liner for each is created, this removes the worry and allows them to create additional tests by cloning existing ones.

84

Time Savings Summary


Less Time Spent on:
Identification of all possible combination Instant Use Case processing and path identification (all possible combination as per selected algorithm) -> better quality testing Instant One-liner Creation Automated population of header information including listing all related/tested requirements and use case Ids

Time needed for Enhancing Tests (needed in manual processing as well):


Alter and Add to Use Case Steps

Enhance add clone POTR(s)


Note: Testers eventually run out of time. If there is very little time spent on know issues, then they can use the saved time to enhance what they are doing. I know there is more I would like to do if I had more time!
85

Dealing with Requirements Change


Requirements Change Type
New POTR only

Impact on Rose Models


New requirements ids are automatically added to the ReqID list in Use Case View; Need to add links to related model element(s) in Logical View Import the use case and the scenarios contained within the use case Import the new scenarios If significant change, import the new scenarios into the Use Case View *and* manually update related design-level scenarios. If not significant modify manually the effected Rose scenarios

Impact on Test Cases


Additional test case(s) can be generated by selecting the new requirements only Generate test from the new use case only and add to the framework Generate test to include the new paths If significant change, generate the new test cases, update them with the changes from the old test cases, store them, and delete the old test cases. If the change is not significant, manually modify the effected test cases

New Use Case added New Scenario added Changes in an existing scenario steps

New Actor Deleted Actor Changed Actor

New Actors are automatically imported; Make sure to generate test cases from make sure to import any new scenarios any new scenarios Inspect and manually delete Manual Change - manually rename the actor in Rose, all existing scenarios are updated automatically

86

PacketIN AFT Usage


(April-May 2003 Snapshot)
Roll-out Plan (Front End) FY03 Re-defined structured usecase format (for AFT) Import baselined SRDs (post Q10) into DOORS current release (AHE R24.1, ISG3.0, TLP3.0) Document SRD using DOORS (eSAE R24.1, eSAE R24.1 SU1) DOORS: SDHLR OA&M Recovery, MIB Chgs; CORC updates; BMC Patrol Rose Designs: SDHLR OA&M Recovery AFT/TMS Usage: metrics collection only DOORS: Filter Conditions; CORC; VARCHAR; TimesTen; Service Key Rose Designs: AFT/TMS usage: TimesTen; CORC; Service Key DOORS: Atomic Transactions; Custom View Tool Rose Designs: AFT/TMS usage: Atomic Transactions; Custom View Tool DOORS: PAM; FW; XGW; MiLife SDK; Camel CC/UI; PM; DIR, UL; US;PM;CHAM; MSG Rose Designs (100%): FW; ISG PacketIN SDK; UL; US;PM;PAM; MiLife SDK;CHAM; DIR; Camel CC/UI, MSG

AHE R24.1 (SRD: 3 of 3 complete; MIB Chgs for R24.2)


eSAE R24.1 (SRD: 5 of 5 completed)

eSAE R24.1 SU1 (SRD: 2 of 2 completed)

ISG R3.0 (SRD: 12 of 12 completed)

AFT/TMS usage: MSG; CHAM (metrics); US; FW; PM; UL; XGW; PAM (metrics)
DOORS: DNS; DTMF; Faster Barge Rose Designs: n/a (designs 100% complete; AFT not applicable to SPA work) AFT/TMS usage: metrics collection only

Teleportal R3.0 (SRD: 3 of 3 completed)

87

Backup: Operationalize the AFT

Telelogic - Bell-Labs - NJIT

Practices
Use Cases
drive iterations

Visual modeling
validate model against scenarios Collaborate on analysis

Early test involvement


Generate tests to evaluate requirements

Reuse of use cases, models, test cases

Better Collaboration Management

89

Focus Area: Use Cases


Better use cases and use-case process
All (SEs, testers and designers) collaborate to define the scope and the list of use cases Make UC available to testers and designers early - generate preliminary XML/tests/Rose scenarios in order to provide feedback to the UC process

If the number of UC is significant, then divide the feature in iterations


Use the syntax-checking tool

90

Focus Area: Early Test Involvement


Testers should:
Ensure requirements are testable Ensure that the product is designed for testability Drive the overall quality improvement of requirements and design

Do early test planning and load definition as outcome of upfront collaboration on defining iterations, use cases, scenarios and feature componentization

91

Focus Area: Model-based Development


Get more from model-based development:
Learn from exiting experience all model levels, scenario-driven structure and reviews, no repeated info in the documents Collaborate with SEs and testers during the analysis utilize CRC cards sessions Optimize for reuse and multiuse Collaborate with testers (and SEs) during the componentization of the feature/product schedule the test loads around the scenarios and iterations

92

Focus Area : Better Management of Collaboration


Structure your iterations around groups of related use cases that contribute to a higher-level goal

Get testers involved early to provide feedback and drive the testability of requirements and the design
Derive the related design scenarios early

Allocate the scenarios to components with high cohesion and low coupling
Define the corresponding test loads

93

Summary
Get it right the first time
Early collaboration: collaborating during the reviews maybe too late collaborate during the definition and artifact creation phases

Reuse as much as possible


Ruse of all artifacts (UC, models, tests, code) from release to release, and if possible from product to product

94

References
Release documentation http://edgeweb2.cb.lucent.com/afti/Deliverables/sti_deli v.htm AFTI References page http://edgeweb2.cb.lucent.com/afti/References/default.h tm Agile RUP summary and some useful papers http://www.stc.lucent.com/~dmm/misc/agile_rup.html

95

Das könnte Ihnen auch gefallen