Requirement Management as a Key Area in e-PLM · 2009-02-26 · Traceability Reports: Milestone Attribute820.30(c) Design Input 2.1. 1.1.3.Each manufacturer shall establish procedures

© 2009 IBM Corporation

®

Requirement Management as a Key Area in e-PLM

PLM Solution RoadShow 2009

IBM Software Group – Product Lifecycle Management

2

목 차

제품개발환경변화에따른대응방안제품개발환경변화에따른대응방안III

e-PLM환경에서의핵심영역e-PLM환경에서의핵심영역IIIIII

요구사항관리솔루션(DOORS) 소개요구사항관리솔루션(DOORS) 소개IIIIIIIII

DOORS - PLM솔루션 IntegrationDOORS - PLM솔루션 IntegrationIVIVIV

DOORS 적용기대효과DOORS 적용기대효과VVV


3

Product Complexity is Increasing Product Development is Fragmented

Shorter Product Lifecycles Complex Development Organizations


4

Product Development Improvement Goals

Accelerate Product Time to Market

Improve Product Quality Reduce Product Development Costs

Design Chain Collaboration

Regulatory Compliance New Product Innovation


5

Complex systems require more types of people working together

Cadence Mentor Catia /UG

Traditional PLM/PDM Domain

Electrical Engineering I.C. Engineering Mechanical EngineeringProduct Management

DOORS

Systems Engineering

DOORS/TAU

Software Engineering

Synergy/TAU Cadence Mentor Catia/UG

Market Planning Concept Design

Complex systems require a ‘holistic’ view of data

Change Requests Impact Analysis Requirements Visibility

Traditional ALM Domain

Future PLM Domain


6

Key Problem: Vertical Silos

Inconsistent rules and processes, that are not being followed by all stakeholders

Isolated information reduces the productivity of the entire team -> Problems occur at integration stages late in lifecycle

Limited traceability ofartifacts and business objects

Minimal reuse of artifacts and minimal process control

Reliance on document-centric communication

Lack of visibility into total development status

Labor intensiveInsider Know-HowFaulty transfers

IterativeProcess V Process V Process

MCAD E/E

HWAssets

SW Development

Assets

EEAssets

SW Governance

???


7

Most PLM Environments today do not have the required level ofprocess, data and application integration

Product Architects

ProgramManager

PortfolioPlanning

Manufacturing Execution

Enterprise Resource

Management

Other Enterprise Applications

Enterprise Application Systems

RequirementsManagement

Data Management

Mechanical Authoring

Data Management

Electrical Authoring

Data Management

Software Authoring

Data Management

Analysis & Simulation

StorageSoftwareServers

Product Engineers Quality Operations Sales Service

Enterprise Product Data Mgmt ECR ECOActionActionAction

ECOECO

Critical enterprise applications often isolated

Limited Integration of Authoring Applications – much manual effort

User data access is isolated to application silos

Poor integration of enterprise PDM and other business systems


8

Extended PLM Solutions to Meet Customer’s Objectives

Portfolio PlanningPortfolio Planning

Concept Development

Concept Development

Product Design

Product Design

Production & Testing


Sales & ServiceSales & Service

Retirement & Disposal


1. Design Chain ManagementCustomer Processes: NPI, ECM, CM…Offerings/Tech: Enterprise Engr Chg BPM, New Product Intro BPM, Config Mgt BPM, Integrated Product Chg Mgt

1. Design Chain ManagementCustomer Processes: NPI, ECM, CM…Offerings/Tech: Enterprise Engr Chg BPM, New Product Intro BPM, Config Mgt BPM, Integrated Product Chg Mgt

3. Software DevelopmentCustomer Processes: Software & Embedded Software Dev…Offerings/Tech: Rational Software and Systems Delivery Platform

3. Software DevelopmentCustomer Processes: Software & Embedded Software Dev…Offerings/Tech: Rational Software and Systems Delivery Platform

6. Portfolio & Program ManagementCustomer Processes: Product Mgt, Portfolio Mgt, Part Commonality & Reuse, Part Repair/Replacement, Aftermarket Part SalesOfferings/Tech: Decision Support & Collab (Portal), Asset & Resource Mgt (Maximo), Commonality & Parts Reuse (WPC)

6. Portfolio & Program ManagementCustomer Processes: Product Mgt, Portfolio Mgt, Part Commonality & Reuse, Part Repair/Replacement, Aftermarket Part SalesOfferings/Tech: Decision Support & Collab (Portal), Asset & Resource Mgt (Maximo), Commonality & Parts Reuse (WPC)

4. Electrical & Electronics DevelopmentCustomer Processes: Logic Design, Layout, Routings...Offerings/Tech: Systems Verification

4. Electrical & Electronics DevelopmentCustomer Processes: Logic Design, Layout, Routings...Offerings/Tech: Systems Verification

5. Mechanical DevelopmentCustomer Processes: Prod Auth, PDM, Prod Sim, Dig Mfg, CPD…Offerings/Tech: CATIA, ENOVIA, DELMIA, Simulation & Analysis

5. Mechanical DevelopmentCustomer Processes: Prod Auth, PDM, Prod Sim, Dig Mfg, CPD…Offerings/Tech: CATIA, ENOVIA, DELMIA, Simulation & Analysis

2. Requirements EngineeringCustomer Processes: Market, Customer & Operations Requirements Management…Offerings/Tech: Rational Requirements Engineering

2. Requirements EngineeringCustomer Processes: Market, Customer & Operations Requirements Management…Offerings/Tech: Rational Requirements Engineering

7. Systems EngineeringCustomer Processes: Functional Design, Systems Knowledge-Based Design…Offerings/Tech: Rational Model Driven System Dev & Engineering, PDIF Phase 3 (future)

7. Systems EngineeringCustomer Processes: Functional Design, Systems Knowledge-Based Design…Offerings/Tech: Rational Model Driven System Dev & Engineering, PDIF Phase 3 (future)

Prod

uct

Inno

vatio

n

BU

SIN

ESS

OB

JEC

TIVE

SPr

oduc

t&

Pro

cess

Inno

vatio

n B

usin

ess

Proc

ess

Inno

vatio

n


9

PLM Goes Integration:

ERP

CRM

PartsMgmt

SCM

StorageServers Software Req.Mgmt

PPM

Enterprise PDM

Product Architects(OEM and/or Suppliers)

Project Management(OEM and/or Suppliers)

Engineering Specialists(OEM and/or Suppliers)

Engineering Specialists(OEM and/or Suppliers)

System View

Information Federation - Management of PLM Enterprise Information Relationships

Business Process Modeling – E.g., Portfolio Planning, Engineering Change, Part Reuse

Product Development Integration FrameworkIBM SOA Foundation

People Collaboration - Role-based PLM Workplace (Portals)

MCAD1

MCADn

ECAD1

EDAn

SW1

SWn

CAPP1

CAPPn

CAE1

CAEn

Maintn

Application SpecificLocal Data Mgmt

AuthoringApplications

IBM Product Development Integration Framework (PDIF) to enable a SOA based PLM process integration


10

Four key areas are part of IBM Extended PLM (ePLM) and the PDIF framework

Enterprise Integration - Management of PLM and Enterprise Information

Enterprise Process Management – Cross-application processes

Product Development Integration Framework

IBM SOA Foundation

RequirementsManagement

Program and Portfolio

Management

Enterprise PDM

Data Management

Mechanical Authoring

ERP

Data Management

Electrical Authoring

Data Management

Software Authoring

Data Management

Analysis & Simulation

Other Enterprise

ApplicationsEAM

Enterprise Collaboration - Portals and dashboards to Applications

Integrated Product Change Management

RequirementsEngineering

Model Driven SystemDevelopment / Engineering

Software & Systems DevelopmentPlatform


11

The Rational Core Solution Set for Extended PLM

Integrated Product Change ManagementAutomation of change management across the product development domains by integrating the Software and Systems Delivery Platform (including Rational ClearCase and ClearQuest) with key PLM vendors such as PTC, Siemens PLM, Oracle Agile, Dassault Enovia.

Model Driven Systems Development / EngineeringProducts and services that leverage Rational capabilities for modeling and best practices for systems engineering and model driven development across multiple design domains (software, hardware, and electronics)

Software and Systems Development PlatformAn end-to-end, open, extensible, standards based platform for software lifecycle management including products and services for modeling, testing, building and delivering software, with anemphasis on meeting the unique requirements of A&D and Auto customers such asDoDAF/MoDAF, DO-178B, AUTOSAR, MISRA, etc.

Requirements EngineeringProducts and services to extend requirements engineering beyond the software development domain (e.g. the systems engineering and EDA domains).


12

Requirements Are Everywhere

RequirementsObj

ectiv

e

Reg

ulat

ion

Criterion NeedRule


13

What is requirements management?

“The purpose of requirements managementis 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

®

“Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure—bigger than bad technology, missed deadlines or change management fiascoes.”

- CIO Magazine, November 2005


14

What drives Requirements Management opportunities?

Systems and software delivered must support business objectives and meet customer needs

• In-house development• Outsourced development• Packaged applications• Systems

Control costs & improve global operational efficiencies

Ensure regulatory compliance in a changing global environment

Deliver systems and software faster but with higher quality

Need to align IT or systems development with business goals / customer needs

Ensure regulatory compliance


15

RM is a lifecycle activity

Configuration/Change Management Tools

Metrics Tools

Project Management Tools

Documentation Tools

Requirements Management & Traceability Tools

RequirementsCapture &

Engineering

Analysis & Design

Tools

ModelingTools

SimulationTools

CodingTools

TestingTools

Portfolio PlanningPortfolio Planning

Concept Development

Concept Development

Product Design

Product Design



Sales & ServiceSales & Service




17

DOORS: Dynamic Object Oriented Requirements SystemDOORS: 요구사항 관리 도구

Gathering/Expressing/Organizing/Tracing/ReviewingAgreeing/Changing/Validating

Telelogic DOORS

like Excel like Word

+


18

Import All Your Data & Create Documents

DOORSDOORS ASCII

Spreadsheet

MS-Project

Tool Integrations*

FrameMaker

HTML

PowerPointWord

OutlookExcel

Microsoft

MS-WordRTF

OLE

ASCII

Spreadsheet

MS-Project

Tool Integrations*

FrameMaker

MS-Word

RTFMS-Word

Print

Direct Entry


19

Start in Word

Simply import into a DOORS document

Microsoft Word import


20

Use your corporate template to export a document

Document

Microsoft Word export

TableBook


21

DOORS Database & Document View

Unlimited hierarchy of Projects/Folderssupports scalability

Deleted Folder

DOORS Documents

Folder

Project

Organize your projects

Improves productivity, reduces errors, increases quality

Everything you need in one window!


22

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














adequacy?


























The usual way of traceability without DOORS?

User Reqts Technical Reqts Test CasesDesign HW/SW

Cross R

ef er en ceW

o rks pa ce


23

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

document to document

Traceability; drag-and-drop linking


24

Traceability view














adequacy?







































adequacy?


























User Reqts Technical Reqts Test CasesDesign

End-to-end visual validation in a single view !


25

Increases customer confidence

Orphan reports & traceability reports show “missing” links

Creation and deletion of links is recorded in history

Traceability verification or “completeness”


27

Traceability taking you outside of DOORS

Everybody should understand the importance of requirements and be able to demonstrate that they meet requirements

By extending traceability to go beyond the boundaries of DOORS, more people are encouraged to work against requirements.

Create links fromDOORS to elements storedwithin applicationsoutside of DOORS

Right click the link indicator

Tool Tip on link indicator


28

URLs bringing you back in to DOORS

Insert links into other applications that connect back to requirements stored in DOORS

Security controls still apply

Authentication still required

URLs can also take you to a DOORS database, Project, Folder, Module or Object


29

DOORS Discussions


30

Differentiating Change Management

Lifecycle Change Management– Telelogic Change for multiple, configurable

processes– Flexible process, user definable states– Integrated into full lifecycle change process– Multiple approvers

DOORS Change Proposal System - CPS– Providing a built in change process for– requirements– Predefined process– Grouped changes ensure requirements

consistency

Configurable Requirement Change Lifecycle

Propose Change

Review TestAssignAssigned

ResolvedConclude

Closed

Defer

Rework


31

How Can I Find Changes Easily?

… a change by this user here…

… shows up as a warning flag to this user here.

If documents are linked …


32

Current Version

PreviousBaseline Change

History

History and Baselines


33

Printing with standard layouts


34

What is DOORS/TraceLine?

DOORS/TraceLine is a DOORS extension for managing and visualizing information and its traceability in DOORS

• Browser based environment

• Requirements visualisation

• View, navigate and edit content

• Arrange information in task or viewpoint-specific views

• Create graphical and textualcontent or traceability reports

• Plug-in your own DXL functions

• For non-technical users, increase productivity, and reduces training

All specifications subject to change without notice


35

What Does DOORS Web Access Look Like?

Navigation Area

Details Area

Document Area

Document Area


36

Teamcenter

BaselinedProject

DOORS

HTML

DOCS

Temporary Location (DOORS Formal, Descriptive & Link Modules)

EX

PO

RT

(HTM

L Format)

IMPORT

EXPORT

HTML

DOCS

Temporary Location (DOORS/TeamcenterModules)

PDM Structure

Updated Data

HTMLFiles

DOORS Items, Attributes & Links

IMPORT

VAULTCurrent Data

HTML

Files

DOORS Items, Attributes & Links

Synchronize

DOORS - Teamcenter Integration View


37

DOORS - MatrixOne Integration View

To the MatrixOne

Object

To the MatrixOne Document

DOORS URL


38

Key DOORS Customers

AutomotiveAerospace/DefenseCommunications Finance, IT and more


39

structured, linked and

traced,

Non-integrated

project data

is imported,

to produce reports of managed

information

Telelogic DOORS:

DOORS


40

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 lifecycle.

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

Boehm ‘76, 88

Relative Cost To Repair:


41

감사합니다.