PLM Solution Roadshow 2009

®
Requirement Management
as a Key Area in e-PLM
PLM Solution RoadShow 2009
© 2009 IBM Corporation

IBM Software Group – Product Lifecycle Management
목차
II 제품개발
제품개발 환경
환경 변화에
변화에 따른
따른 대응
대응 방안
방안
II
II e-PLM환경에서의 핵심
e-PLM환경에서의 핵심 영역
영역
IIII
II 요구사항관리
요구사항관리 솔루션(DOORS)
솔루션(DOORS) 소개
소개
IV
IV DOORS
DOORS -- PLM솔루션
PLM솔루션 Integration
Integration
VV DOORS 적용
DOORS 적용 기대
기대 효과
효과
2
Product Complexity is Increasing Product Development is Fragmented
Shorter Product Lifecycles Complex Development Organizations
3
Product Development Improvement Goals

Accelerate Product Time to Market
Improve Product Quality Reduce Product

Development Costs
Design Chain Collaboration
Regulatory Compliance New Product Innovation
4
Complex systems require more types of people working together
Market Planning Concept Design
Product Management Systems Engineering Software Engineering Electrical Engineering I.C. Engineering Mechanical Engineering
DOORS DOORS/TAU Synergy/TAU Cadence Mentor Catia/UG

Cadence Mentor Catia /UG
Traditional ALM Domain Traditional PLM/PDM Domain
Change Requests Impact Analysis Requirements Visibility
Future PLM Domain
Complex systems require a ‘holistic’ view of data
5
Key Problem: Vertical Silos

Inconsistent rules and
processes, that are not
being followed by all
stakeholders
Isolated information
reduces the productivity of SW MCAD E/E Governance
the entire team
-> Problems occur at Iterative
Process V Process V Process
integration stages late in ???
lifecycle
Limited traceability of SW HW EE
artifacts and business Development Assets Assets
objects Assets
Minimal reuse of artifacts

and minimal process control Labor intensive
Insider Know-How
Reliance on document- Faulty transfers
centric communication
Lack of visibility into total

development status
6
Most PLM Environments today do not have the required level of

process, data and application integration
Program Product Product
Quality Operations Sales Service
Manager Architects Engineers
Critical enterprise Limited Integration of User data access is Poor integration of enterprise
applications often Authoring Applications isolated to application PDM and other business systems
isolated – much manual effort silos
ECO Action
Enterprise Product Data Mgmt ECR ECO
ECO Action
Action
Enterprise Application Systems
Data Data Data Data

Portfolio Requirements Management Management Management Management Enterprise
Manufacturing Other Enterprise
Resource
Planning Management Execution Applications
Management
Mechanical Electrical Software Analysis &

Authoring Authoring Authoring Simulation
Servers
Software Storage
7
Extended PLM Solutions to Meet Customer’s Objectives

Business Process
Portfolio
Portfolio Concept
Concept Product
Product Production
Production &
& Sales
Sales &
& Retirement
Retirement &
&
Innovation
Planning
Planning Development
Development Design
Design Testing
Testing Service
Service Disposal
Disposal
1.
1. Design
Design Chain
Chain Management
Management
Customer
Customer Processes:
Processes: NPI,
NPI, ECM,
ECM, CM…
CM…
Offerings/Tech:
Offerings/Tech: Enterprise Engr Chg
Enterprise Engr Chg BPM,
BPM, New
New Product
Product Intro
Intro BPM,
BPM, Config
Config Mgt
Mgt BPM,
BPM, Integrated
Integrated Product
Product Chg
Chg Mgt
Mgt
2.
2. Requirements
Requirements Engineering
Engineering
BUSINESS OBJECTIVES
Customer
Customer Processes:
Processes: Market,
Market, Customer
Customer && Operations
Operations Requirements
Requirements Management…
Management…
Offerings/Tech:
Offerings/Tech: Rational
Rational Requirements
Engineering
3.
3. Software
Software Development
Innovation
Development
Product
Customer
Customer Processes:
Processes: Software
Software && Embedded
Embedded Software
Software Dev…
Dev…
Offerings/Tech:
Rational Software
Software and
and Systems
Systems Delivery
Delivery Platform
Platform
4.
4. Electrical
Electrical &
& Electronics
Electronics Development
Development
Customer
Customer Processes:
Processes: Logic
Logic Design,
Design, Layout,
Layout, Routings...
Routings...
Offerings/Tech:
Offerings/Tech: Systems
Systems Verification
Verification
5.
5. Mechanical
Mechanical Development
Development
Customer
Customer Processes:
Processes: Prod
Prod Auth,
Auth, PDM,
PDM, Prod
Prod Sim,
Sim, Dig
Dig Mfg,
Mfg, CPD…
CPD…
Offerings/Tech:
Offerings/Tech: CATIA,
CATIA, ENOVIA,
ENOVIA, DELMIA,
DELMIA, Simulation
Simulation && Analysis
Analysis
6.
6. Portfolio
Portfolio &
& Program
Program Management
Management
Innovation
& Process
Customer
Product
Customer Processes:
Processes: Product
Product Mgt,
Mgt, Portfolio
Portfolio Mgt,
Mgt, Part
Part Commonality
Commonality && Reuse,
Reuse, Part
Part Repair/Replacement,
Repair/Replacement, Aftermarket
Aftermarket Part
Part Sales
Sales
Offerings/Tech:
Offerings/Tech: Decision
Decision Support
Support && Collab
Collab (Portal),
(Portal), Asset
Asset && Resource
Resource Mgt
Mgt (Maximo),
(Maximo), Commonality
Commonality && Parts
Parts Reuse
Reuse (WPC)
(WPC)
7.
7. Systems
Systems Engineering
Engineering
Customer
Customer Processes:
Processes: Functional
Functional Design,
Design, Systems
Systems Knowledge-Based
Knowledge-Based Design…
Design…
Offerings/Tech:
Rational Model
Model Driven
Driven System
System Dev
Dev && Engineering,
Engineering, PDIF
PDIF Phase
Phase 33 (future)
(future)
8
PLM Goes Integration:

IBM Product Development Integration Framework (PDIF) to enable a SOA based PLM process
integration
Project Management Product Architects Engineering Specialists Engineering Specialists
(OEM and/or Suppliers) (OEM and/or Suppliers) (OEM and/or Suppliers) (OEM and/or Suppliers)
People Collaboration - Role-based PLM Workplace (Portals)
Business Process Modeling – E.g., Portfolio Planning, Engineering Change, Part Reuse
System View
Information Federation - Management of PLM Enterprise Information Relationships

Product Development Integration Framework
IBM SOA Foundation
ERP
Application Specific
Local Data Mgmt Parts
Mgmt
Authoring MCAD MCAD ECAD EDA SW SW CAPP CAPP CAE CAE Maint
Applications 1 n 1 n 1 n 1 n 1 n n
SCM
CRM
Enterprise PDM
PPM
Servers Software Storage Req.

Mgmt
9
Four key areas are part of IBM Extended PLM (ePLM) and
the PDIF framework
Enterprise Collaboration - Portals and dashboards to Applications
Enterprise Process Management – Cross-application processes
Enterprise Integration - Management of PLM and Enterprise Information
Product Development Integration Framework

IBM SOA Foundation
Integrated Product Change
Management
Data Data Data Data

Management Management Management Management
Program and Other
Requirements Enterprise
Portfolio ERP EAM Enterprise
Management PDM
Management Applications
Mechanical Electrical Software Analysis &
Authoring Authoring Authoring Simulation
Requirements Software &
Engineering Systems
Development
Platform
Model Driven System
Development / Engineering
10
The Rational Core Solution Set for Extended PLM
Integrated Product Change Management

Automation 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.
Software and Systems Development Platform

An end-to-end, open, extensible, standards based platform for software lifecycle management
including products and services for modeling, testing, building and delivering software, with an
emphasis on meeting the unique requirements of A&D and Auto customers such as
DoDAF/MoDAF, DO-178B, AUTOSAR, MISRA, etc.
Model Driven Systems Development / Engineering

Products 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)
Products and services to extend requirements engineering beyond the software development
domain (e.g. the systems engineering and EDA domains).
11
Requirements Are Everywhere
ion
le
e
u la t
Ru
t iv
d
ec
Cr i e
Re g
t er e
ion
bj
N
O
Requirements
12
What is requirements management?
“The purpose of requirements management

is to establish a common understanding between the customer and the
… project ... This agreement with the customer is the basis for
planning and managing the … project.”
The Capability Maturity Model for Software®(CMM ) from the
Software Engineering Institute at Carnegie Mellon University.
- www.sei.cmu.edu/cmm
“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
13
What drives Requirements Management opportunities?
Need to align IT or systems

development with business
goals / customer needs
Deliver systems and software

faster but with higher quality
Control costs & improve

global operational
efficiencies
• In-house development
• Outsourced development
Ensureregulatory
Ensure regulatory compliance
compliance • Packaged applications
in a changing global
environment • Systems
Systems and software delivered must support business

objectives and meet customer needs
14
RM is a lifecycle activity
Portfolio
Portfolio Concept
Concept Product
Product Production
Production &
& Sales
Sales &
& Retirement
Retirement &
&
Planning
Planning Development
Development Design
Design Testing
Testing Service
Service Disposal
Disposal
Requirements Analysis
Modeling Simulation Coding Testing
Capture & & Design
Tools Tools Tools Tools
Engineering Tools
Requirements Management & Traceability Tools
Documentation Tools
Project Management Tools
Configuration/Change Management Tools
Metrics Tools
15
Telelogic DOORS
DOORS: Dynamic Object Oriented Requirements System
DOORS: 요구사항 관리 도구
Gathering/Expressing/Organizing/Tracing/Reviewing
Agreeing/Changing/Validating
like Word like Excel
17
Import All Your Data & Create Documents
Direct Entry
Word
MS-Word
PowerPoint
Microsoft
MS-Word RTF Excel
Outlook
OLE HTML
RTF MS-Word
ASCII
DOORS ASCII
Spreadsheet
Spreadsheet
MS-Project
MS-Project
Tool Integrations* Tool Integrations*
FrameMaker FrameMaker
Print
18
Microsoft Word import
Start in Word
Simply import into

a DOORS
document
19
Microsoft Word export
Document
Table
Book
Use your corporate template to export a document
20
DOORS Database & Document View

Organize your projects Everything you need in one window!
Folder
Deleted Folder
Project
DOORS Documents
Unlimited hierarchy of Projects/Folders Improves productivity,

supports scalability reduces errors, increases quality
21
The usual way of traceability without DOORS?
1.
User Reqts
820.30(b) Design and Development Planning
Technical Reqts 1. 820.30(b) Design and Development Planning
Design HW/SW Test Cases
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 Each manufacturer shall establish and maintain plans that describe or reference the design1.1. Identify impacted elements due to a change in another element
and development 1.1. Identify impacted elements due to a change in another element
activities and define responsibility for implementation. activities and define responsibility for implementation.
1. Capture design and related information • Traceability Reports: consistency
1. Capturewith driving
design design
and related elements
information • Traceability Reports: consistency with driving design elements
shall identify and describe the interfaces with different groups or activities that •provide, • Impact Reports: other design elements affected
1.1. Input electronically formatted data Impact Reports: other design1.1. Input electronically
elements affected formatted data
The plans shall identify and describe the interfaces with different groups or activities that provide, or result The plans
1.2. Reference external information sources or result 1.2. Reference external information sources
in, input to the design and development process. in, input to the design and development process.
1.3. Reference external documentation • Links to impacted design elements 1.3. Reference external documentation • 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. 2. The plans shall be reviewed as design and development evolves.
Store design and related information procedure 2. Store design and related information procedure
The plans shall be updated 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.1. Identify and tag design information as unique “design elements”
The plans shall be approved as design and development evolves. • Traceability Reports: Procedure
Attribute • Traceability Reports: Procedure Attribute
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
Work space
2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element
2. 820.30(c) Design Input 2. 820.30(c) Design Input
2.2.2. Organize by inter-relationships • Traceability Reports: Milestone Attribute
2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a 2.3. Ensure all design elements are2.1. Each manufacturer shall establish procedures to ensure that the design requirements
available relating
1.1.3. Createto backward
a traces to design elements
2.3. Ensure within
all design and are
elements across Design Control
available 1.1.3.Create backward traces to design elements within and across Design Control
device are appropriate and address the intended use of the device, including the needs of the user 2.3.1. Store design elements by Designdevice are appropriate
Control Guidance and address the intended use of the device, including the needs of
Element the user Elements
Guidance 2.3.1. Store design elements by Design Control Guidance Element Guidance Elements
and patient. 2.3.2. Store design elements and theirandhistorical
patient. values 2.3.2. Store design elements and their historical values
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating • Traceability
to a Reports: Linked design elements • Traceability Reports: Linked design elements
device are appropriate and address the intended use of the device, including the needs of the user 3. Manage all user needs device are appropriate and address the intended use of the device, including the1.1.4. needs Create forward impacts3.to design
of the user Manage elements within and across any organizational
all user needs 1.1.4.Create forward impacts to design elements within and across any organizational
and patient. 3.1. Identify the source of the user need and patient. procedure 3.1. Identify the source of the user need procedure
2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.3. The procedures shall include a mechanism for addressing incomplete requirements.
2.4. The procedures shall include a mechanism for addressing ambiguous requirements.
3.2. Identify all user types (groups)
• Impact Reports: Procedure Attribute
3.2. Identify all user types (groups) • Impact Reports: Procedure Attribute
3.3. Identify the customer (s) 3.3. Identify
1.1.5.Create forward impacts to design the customer
elements within(s) and across any project milestone 1.1.5.Create forward impacts to design elements within and across any project milestone
2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients
2.6. The design input requirements shall be documented by a designated individual(s). 3.5. State the intended use of the 2.6.
productThe(family)
design input requirements shall be documented by a designated individual(s). • Impact Reports: Milestone Attribute
3.5. State the intended use of the product (family) • Impact Reports: Milestone Attribute
2.7. The design input requirements shall be reviewed by a designated individual(s). 2.7.forThe
3.6. Capture the acceptance criteria eachdesign input requirements shall be reviewed by a designated individual(s). 1.1.6.Create forward impacts to design
user need elements
3.6. Capture within and
the acceptance across
criteria Design
for each Control
user need 1.1.6.Create forward impacts to design elements within and across Design Control
2.8. The design input requirements shall be approved by a designated individual(s). 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 requirements2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.
4.
shall be documented. • Impact Reports: Linked 4. Manage
designdesign input requirements
elements • Impact Reports: Linked design elements
4.1. Identify the source of the requirement 4.1. Identify the source of the requirement
2.10. Questions. 2.10. Questions. 1.2. Associate changed design elements with related elements 1.2. Associate changed design elements with related elements
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 control of 4.3. Capture requirement description and 2.10.1. Summarize the manufacturer's written procedure(s) for identification and
attributes • control
LinkofChange Design Object 4.3.withCapture
affected design element(s)
requirement description and attributes • Link Change Design Object with affected design element(s)
design input. 4.4. Capture acceptance criteria design input. • Traceability Links and Reports 4.4. from affected
Capture design
acceptance element(s)
criteria • Traceability Links and Reports from affected design element(s)
2.10.2. From what sources are design inputs sought? 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
4.5. Assign responsibility for each requirement • Impact Links and Reports from 4.5. affected
Assign responsibility for each requirement
design element(s) • 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
list additional aspects.) 4.7. Manage ambiguous requirements list additional aspects.) 1.2.1.Associate design element changes with decisions, rationale, and approval authority
4.7. Manage ambiguous requirements
1.2.1.Associate design element changes with decisions, rationale, and approval authority
2.10.3.1. intended use 4.8. Manage conflicting requirements 2.10.3.1. intended use information 4.8. Manage conflicting requirements information
2.10.3.2. user/patient/clinical 4.9. Approve all requirements 2.10.3.2. user/patient/clinical • Change Decision Objects4.9. with following
Approve Attributes:
all requirements • Change Decision Objects with following Attributes:
2.10.3.3. performance characteristics 2.10.3.3. performance characteristics
2.10.3.4. safety 2.10.3.4. safety • Disposition Attribute • Disposition Attribute
5. Manage acceptance 5. Manage acceptance
2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 2.10.3.5. limits and tolerances • Decision Attribute 5.1. Ensure the acceptance of every user need • Decision Attribute
2.10.3.6. risk analysis 2.10.3.6.
5.2. Ensure the acceptance of every design input requirement risk analysis • Rationale Attribute 5.2. Ensure the acceptance of every design input requirement • Rationale Attribute
2.10.3.7. toxicity and biocompatibility 5.3. Document the results of every user need 2.10.3.7.
acceptancetoxicity
test and biocompatibility • Owner Attribute 5.3. Document the results of every user need acceptance test • Owner Attribute
2.10.3.8. electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. electromagnetic compatibility (EMC)
2.10.3.9. compatibility with accessories/auxiliary devices
input requirements test • Management Approval Attribute5.4. Document the results of every design input requirements test • Management Approval Attribute
5.5. Make acceptance results available 2.10.3.9. compatibility with accessories/auxiliary devices
2.10.3.10. compatibility with the environment of intended use 2.10.3.10. compatibility with the environment of intended use 1.2.2.Provide associations within5.5. andMakeacrossacceptance results available
any organizational procedure 1.2.2.Provide associations within and across any organizational procedure
2.10.3.11. human factors 6. Manage change 2.10.3.11. human factors • Change Design Object 6. Traceability
Manage change Link on Procedure Attribute • Change Design Object Traceability Link on Procedure Attribute
2.10.3.12. physical/chemical characteristics 2.10.3.12. physical/chemical characteristics
2.10.3.13. labeling/packaging
6.1. Maintain history of design element changes
• Change Design Object Impacts Link history
6.1. Maintain on Procedure
of design Attribute
element changes • Change Design Object Impacts Link on Procedure Attribute
6.1.1. Make complete change history available 1.2.3.Provide associations within and 6.1.1. Makeany
across complete
projectchange history available
milestone 1.2.3.Provide associations within and across any project milestone
2.10.3.14. reliability 2.10.3.14. reliability
6.1.2. Maintain history within and across any organizational procedure 6.1.2. Maintain history within and across any organizational procedure
2.10.3.15. statutory and regulatory requirements 6.1.3. Maintain history within and across 2.10.3.15.
any projectstatutory and regulatory requirements
milestone • Change Design Object Traceability Link on Milestone Attribute
6.1.3. Maintain history within and across any project milestone • Change Design Object Traceability Link on Milestone Attribute
2.10.3.16. voluntary standards 6.1.4. Maintain history within and across 2.10.3.16.
any Design voluntary
Control standards
Guidance Elements • Change Design Object Impacts 6.1.4.Link on Milestone
Maintain history within Attribute
and across any Design Control Guidance Elements • Change Design Object Impacts Link on Milestone Attribute
2.10.3.17. manufacturing processes 6.2. Capture frequency and nature of element 2.10.3.17.
changes manufacturing processes 1.2.4.Provide associations within6.2. andCapture
acrossfrequency
Design and Control
natureGuidance Elements
of element changes 1.2.4.Provide associations within and across Design Control Guidance Elements
2.10.3.18. sterility 6.2.1. Provide rationale for change 2.10.3.18. sterility
2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.19. MDRs/complaints/failures and other historical data • Change Design Object Traceability 6.2.1. Provide
Linkrationale
to traced for design
change elements • Change Design Object Traceability Link to traced design elements
6.2.2. Describe decisions made 6.2.2. Describe decisions made
2.10.3.20. design history files (DHFs) 6.2.3. Identify approval authority for the2.10.3.20.
change design history files (DHFs) • Change Design Object Impacts Link to linked design elements
6.2.3. Identify approval authority for the change • Change Design Object Impacts Link to linked design elements
2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.4.of approving
6.2.4. Capture date, time, and signature For the specific 1.3. Mange
design covered, how were the design input requirements
authority the change process
identified? 6.2.4. Capture date, time, and signature of approving authority 1.3. Mange the change process
2.10.5. For the specific design covered, how were the design input requirements reviewed for 6.3. Identify impacted elements due to2.10.5. For
in the specific design covered, how were the design input requirements reviewed forChange Module
adequacy?
a change
adequacy?
another element • Design 6.3. Identify impacted elements due to a change in another element • Design Change Module
6.3.1. Create backward traces to design elements within and across any organizational procedure • Design Change Reports 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
• Object History Reports • Object History Reports
• Versions • Versions
Cross Reference
• Baselines • Baselines
22
Traceability; drag-and-drop linking
Drag-and-drop
to link within a
document . . . . . . or from
document to
document
23
Traceability view
User Reqts Technical Reqts Design Test Cases
1. 820.30(b) Design and Development Planning 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 Each manufacturer shall establish and maintain plans that describe or reference the design1.1. Identify impacted elements due to a change in another element
and development 1.1. Identify impacted elements due to a change in another element
activities and define responsibility for implementation. activities and define responsibility for implementation.
1. Capture design and related information • Traceability Reports: consistency
1. Capturewith driving
design design
and related elements
information • Traceability Reports: consistency with driving design elements
1.1. Input electronically formatted data
The plans shall identify and describe the interfaces with different groups or activities that provide, or result The plans • Impact Reports:
shall identify and describe the interfaces with different groups or activities that provide, or result other 1.1.
design Input electronically
elements affected formatted data • Impact Reports: other design elements affected
1.2. Reference external information sources 1.2. Reference external information sources
in, input to the design and development process. in, input to the design and development process.
1.3. Reference external documentation • Links to impacted design elements1.3. Reference external documentation • 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. 2. The plans shall be reviewed as design and development evolves.
Store design and related information procedure 2. Store design and related information procedure
The plans shall be updated 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.
The plans shall be approved as design and development evolves. • Traceability Reports: Procedure
Attribute • Traceability Reports: Procedure Attribute
2.2. Organize design elements 2.2. Organize design elements
2.2.1. Organize by Design Control Guidance Element
1.1.2.Create backward traces to design elements within and across any project milestone
2.2.1. Organize by Design Control Guidance Element
1.1.2.Create backward traces to design elements within and across any project milestone
2. 820.30(c) Design Input 2. 820.30(c) Design Input
2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a 2.3. Ensure all design elements are2.1. Each manufacturer shall establish procedures to ensure that the design requirements
available relating
1.1.3. Createto backward
a traces to design elements
2.3. Ensure within
all design and are
elements across Design Control
available 1.1.3.Create backward traces to design elements within and across Design Control
device are appropriate and address the intended use of the device, including the needs of the user 2.3.1. Store design elements by Designdevice are appropriate
Control Guidance and address the intended use of the device, including the needs of
Element the user Elements
Guidance 2.3.1. Store design elements by Design Control Guidance Element Guidance Elements
and patient. 2.3.2. Store design elements and theirandhistorical
patient. values 2.3.2. Store design elements and their historical values
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating • Traceability
to a Reports: Linked design elements • Traceability Reports: Linked design elements
device are appropriate and address the intended use of the device, including the needs of the user 3. Manage all user needs device are appropriate and address the intended use of the device, including the 1.1.4.
needs Create
of the forward
user impacts to design elements
3. Manage all user needs within and across any organizational 1.1.4.Create forward impacts to design elements within and across any organizational
and patient. 3.1. Identify the source of the user need and patient. procedure 3.1. Identify the source of the user need procedure
2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.3. The procedures shall include a mechanism for addressing incomplete requirements.
3.2. Identify all user types (groups)
• Impact Reports: Procedure Attribute
3.2. Identify all user types (groups) • Impact Reports: Procedure Attribute
3.3. Identify the customer (s) 3.3. Identify the customer (s)
1.1.5.Create forward impacts to design elements within and across any project milestone 1.1.5.Create forward impacts to design elements within and across any project milestone
2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients
2.6. The design input requirements shall be documented by a designated individual(s). 3.5. State the intended use of the 2.6.
productThe(family)
design input requirements shall be documented by a designated individual(s). • Impact Reports: Milestone Attribute
3.5. State the intended use of the product (family) • Impact Reports: Milestone Attribute
2.7. The design input requirements shall be reviewed by a designated individual(s). 2.7.forThe
3.6. Capture the acceptance criteria eachdesign input requirements shall be reviewed by a designated individual(s). 1.1.6.Create forward impacts to design
user need elements
3.6. Capture within and
the acceptance across
criteria Design
for each Control
user need 1.1.6.Create forward impacts to design elements within and across Design Control
2.8. The design input requirements shall be approved by a designated individual(s). 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, 2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.
4. Manage design input requirements
shall be documented. • Impact Reports: Linked 4. Manage
designdesign input requirements
elements • Impact Reports: Linked design elements
4.1. Identify the source of the requirement 4.1. Identify the source of the requirement
2.10. Questions. 2.10. Questions. 1.2. Associate changed design elements with related elements 1.2. Associate changed design elements with related elements
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 control of 4.3. Capture requirement description and 2.10.1. Summarize the manufacturer's written procedure(s) for identification and
attributes • control
LinkofChange Design Object 4.3.withCapture
affected design element(s)
requirement description and attributes • Link Change Design Object with affected design element(s)
design input. 4.4. Capture acceptance criteria design input. • Traceability Links and Reports 4.4. from affected
Capture design
acceptance element(s)
criteria • Traceability Links and Reports from affected design element(s)
2.10.2. From what sources are design inputs sought? 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
4.5. Assign responsibility for each requirement • Impact Links and Reports from 4.5. affected
Assign responsibility for each requirement
design element(s) • 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
list additional aspects.) 4.7. Manage ambiguous requirements list additional aspects.) 1.2.1. Associate design element changes with decisions, rationale, and approval authority
4.7. Manage ambiguous requirements
1.2.1.Associate design element changes with decisions, rationale, and approval authority
2.10.3.1. intended use 4.8. Manage conflicting requirements 2.10.3.1. intended use information 4.8. Manage conflicting requirements information
2.10.3.2. user/patient/clinical 4.9. Approve all requirements 2.10.3.2. user/patient/clinical • Change Decision Objects4.9. with following
Approve Attributes:
all requirements • Change Decision Objects with following Attributes:
2.10.3.3. performance characteristics 2.10.3.3. performance characteristics
2.10.3.4. safety 2.10.3.4. safety • Disposition Attribute • Disposition Attribute
5. Manage acceptance 5. Manage acceptance
2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 2.10.3.5. limits and tolerances • Decision Attribute 5.1. Ensure the acceptance of every user need • Decision Attribute
2.10.3.6. risk analysis 5.2. Ensure the acceptance of every design2.10.3.6. risk analysis
input requirement • Rationale Attribute 5.2. Ensure the acceptance of every design input requirement • Rationale Attribute
2.10.3.7. toxicity and biocompatibility 5.3. Document the results of every user need 2.10.3.7.
acceptancetoxicity
test and biocompatibility • Owner Attribute 5.3. Document the results of every user need acceptance test • Owner Attribute
2.10.3.8. electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. electromagnetic compatibility (EMC)
2.10.3.9. compatibility with accessories/auxiliary devices
input requirements test • Management Approval Attribute5.4. Document the results of every design input requirements test • Management Approval Attribute
5.5. Make acceptance results available 2.10.3.9. compatibility with accessories/auxiliary devices 5.5. Make acceptance results available
2.10.3.10. compatibility with the environment of intended use 2.10.3.10. compatibility with the environment of intended use 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.11. human factors 6. Manage change 2.10.3.11. human factors • Change Design Object 6. Traceability
Manage change Link on Procedure Attribute • Change Design Object Traceability Link on Procedure Attribute
2.10.3.12. physical/chemical characteristics 2.10.3.12. physical/chemical characteristics
6.1. Maintain history of design element changes
• Change Design Object Impacts Link history
6.1. Maintain on Procedure
of design Attribute
element changes • Change Design Object Impacts Link on Procedure Attribute
6.1.1. Make complete change history available 1.2.3.Provide associations within and 6.1.1. Makeany
across complete
projectchange history available
milestone 1.2.3.Provide associations within and across any project milestone
2.10.3.14. reliability 6.1.2. Maintain history within and across 2.10.3.14. reliabilityprocedure
any organizational 6.1.2. Maintain history within and across any organizational procedure
2.10.3.15. statutory and regulatory requirements 6.1.3. Maintain history within and across 2.10.3.15.
any project statutory and regulatory requirements
milestone • Change Design Object Traceability Link on Milestone Attribute
6.1.3. Maintain history within and across any project milestone • Change Design Object Traceability Link on Milestone Attribute
2.10.3.16. voluntary standards 6.1.4. Maintain history within and across 2.10.3.16.
any Design voluntary
Control standards
Guidance Elements • Change Design Object Impacts 6.1.4.Link on Milestone
Maintain Attribute
history within and across any Design Control Guidance Elements • Change Design Object Impacts Link on Milestone Attribute
2.10.3.17. manufacturing processes 6.2. Capture frequency and nature of element 2.10.3.17.
changes manufacturing processes 1.2.4.Provide associations within6.2. andCapture
acrossfrequency
Design and Control
natureGuidance Elements
of element changes 1.2.4.Provide associations within and across Design Control Guidance Elements
2.10.3.18. sterility 6.2.1. Provide rationale for change 2.10.3.18. sterility
2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.19. MDRs/complaints/failures and other historical data • Change Design Object Traceability 6.2.1. Provide
Linkrationale
to tracedfor design
change elements • Change Design Object Traceability Link to traced design elements
6.2.2. Describe decisions made 6.2.2. Describe decisions made
2.10.3.20. design history files (DHFs) 6.2.3. Identify approval authority for the2.10.3.20.
change design history files (DHFs) • Change Design Object Impacts Link to linked design elements
6.2.3. Identify approval authority for the change • Change Design Object Impacts Link to linked design elements
2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.4. For the specific
6.2.4. Capture date, time, and signature of approving authority design covered, how were the design input 1.3.
requirements Mange the
identified? change process 6.2.4. Capture date, time, and signature of approving authority 1.3. Mange the change process
2.10.5. For the specific design covered, how were the design input requirements reviewed for 6.3. Identify impacted elements due to2.10.5. For
in the specific design covered, how were the design input requirements reviewed forChange Module
adequacy?
a change
adequacy?
another element • Design 6.3. Identify impacted elements due to a change in another element • Design Change Module
6.3.1. Create backward traces to design elements within and across any organizational procedure • Design Change Reports 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
• Object History Reports • Object History Reports
• Versions • Versions
• Baselines • Baselines
End-to-end visual validation in a single view !

24
Traceability verification or “completeness”
Increases customer confidence
Orphan reports
& traceability
reports show
“missing” links
Creation and
deletion of links
is recorded in
history
25
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 from
DOORS to elements stored
within applications
outside of DOORS
Tool Tip on link indicator
Right click the link indicator
27
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
28
DOORS Discussions
29
Differentiating Change Management
Lifecycle Change Management Configurable Requirement Change Lifecycle

– Telelogic Change for multiple, configurable Rework
processes Propose Review Assi

Resolved
Test
Closed
Conclude
Change Assigned gn
– Flexible process, user definable states

– Integrated into full lifecycle change process Defer
– Multiple approvers
DOORS Change Proposal System - CPS

– Providing a built in change process for
– requirements
– Predefined process
– Grouped changes ensure requirements
consistency
30
How Can I Find Changes Easily?
If documents are linked …
… shows up as a
… a change by warning flag to this
this user here… user here.
31
History and Baselines
Current
Version
Previous
Change
Baseline
History
32
Printing with standard layouts
33
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 textual
content 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 34

What Does DOORS Web Access Look Like?
Document Area
Details Area
Navigation
Area
Document Area
35
DOORS - Teamcenter Integration View
DOORS HTML Temporary Location

IMPORT DOCS (DOORS/Teamcenter
Baselined Modules)
Project
(HTML Format)
Teamcenter
EXPORT
EXPORT
VAULT
PDM
Current Data Structure
HTML DOORS S
Items, yn
Temporary Location Files Attribute
ch
ro
(DOORS Formal, s & Links n
ize
Descriptive & Link Updated Data
Modules)
HTML HTML DOORS
Items,
DOCS
IMPORT Files Attribute
s &
Links
36
DOORS - MatrixOne Integration View
To the
MatrixOne
Document
To the
MatrixOne
Object
DOORS URL
37
Key DOORS Customers

Communications Aerospace/Defense Automotive Finance, IT and more
38
Telelogic DOORS:
Non-
integrated
project data
is imported,
structured,
linked and
traced,
to produce
reports of
managed
DOORS
information
39
Relative Cost To Repair:
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.
Boehm ‘76, 88
56% of all bugs can be traced to errors

made during the requirements stage
40
감사합니다.
41

PLM Solution Roadshow 2009 - 07

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PLM Solution Roadshow 2009 - 07

Uploaded by

Copyright:

Available Formats

®

© 2009 IBM Corporation

 Product Complexity is Increasing  Product Development is Fragmented

 Shorter Product Lifecycles  Complex Development Organizations

Product Development Improvement Goals

Improve Product Quality Reduce Product

Design Chain Collaboration

Regulatory Compliance New Product Innovation

Complex systems require more types of people working together

Market Planning Concept Design

DOORS DOORS/TAU Synergy/TAU Cadence Mentor Catia/UG

Traditional ALM Domain Traditional PLM/PDM Domain

Change Requests Impact Analysis Requirements Visibility

Future PLM Domain

Complex systems require a ‘holistic’ view of data

Key Problem: Vertical Silos

 Minimal reuse of artifacts

 Lack of visibility into total

Most PLM Environments today do not have the required level of

Enterprise Application Systems

Data Data Data Data

Mechanical Electrical Software Analysis &

Extended PLM Solutions to Meet Customer’s Objectives

PLM Goes Integration:

People Collaboration - Role-based PLM Workplace (Portals)

Information Federation - Management of PLM Enterprise Information Relationships

Servers Software Storage Req.

Enterprise Collaboration - Portals and dashboards to Applications

Enterprise Process Management – Cross-application processes

Enterprise Integration - Management of PLM and Enterprise Information

Product Development Integration Framework

Data Data Data Data

The Rational Core Solution Set for Extended PLM

Integrated Product Change Management

Software and Systems Development Platform

Model Driven Systems Development / Engineering

Requirements Are Everywhere

What is requirements management?

“The purpose of requirements management

“Analysts report that as many as 71 percent of software

What drives Requirements Management opportunities?

Need to align IT or systems

Deliver systems and software

Control costs & improve

Systems and software delivered must support business

Requirements Management & Traceability Tools

Project Management Tools

Configuration/Change Management Tools

like Word like Excel

Import All Your Data & Create Documents

Microsoft Word import

 Simply import into

Microsoft Word export

DOORS Database & Document View

Unlimited hierarchy of Projects/Folders Improves productivity,

The usual way of traceability without DOORS?

Traceability; drag-and-drop linking

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

Traceability verification or “completeness”

Increases customer confidence

Traceability taking you outside of DOORS

 Everybody should understand the importance of requirements and

Product Complexity is Increasing Product Development is Fragmented

Shorter Product Lifecycles Complex Development Organizations

Minimal reuse of artifacts

Lack of visibility into total

Simply import into

Everybody should understand the importance of requirements and

Insert links into other applications that connect

Lifecycle Change Management Configurable Requirement Change Lifecycle

DOORS Change Proposal System - CPS

DOORS/TraceLine is a DOORS extension for managing and visualizing