Copyright 2004, Carnegie Mellon University. All rights reserved.
ENGINEERING DEPARTMENT PROCEDURE
EDP – P01
ENGINEERING DEPARTMENT
GLOBAL SOLUTIONS DEVELOPMENT
TITLE: ENGINEERING DEPARTMENT PRODUCT DESIGN PLAN
PURPOSE
<<policy>>The purpose of this instruction is to state the department policy that all engineering programs,
contractural and strategic, without distinction, be designed in accordance with the Engineering
Department Product Design Plan.
REFERENCE
None.
BACKGROUND
<<process and procedure/guideline and templates>>The Product Design Plan (PDP) is a systematic
process for program identification, planning, execution, and monitoring, to assure that the requirements
and goals of the program are met through effective utilization of the department's skill and resources.
This process features the use of checkpoints, all or some of which are included in all engineering
programs. It is intended that the engineer's understanding and implementation of the process will result in
a systematic design approach. It is further intended that users will continually review and improve the
PDP.
<<need mechanism for review/feedback/improvement to be stated or referred to>>
<<combo of policy and guideline>>PROCEDURE
1.
<<policy>>The PDP shall be incorporated into all new engineering programs and design related
activities. The extent of incorporation into existing programs shall be determined by the
appropriate functional Engineering Manager, Lead Engineer and Program Manager (for customer
contracts).
2.
<<policy>>The PDP will provide for the implementation of the design process through the use of
a system of checkpoints to assure that the process is on target through all phases of the product life
cycle, including contract closure.
3.
<<process--tailoring guidelines>>The checkpoints included in the PDP are divided into two
groups: required and conditionally required. Required checkpoints must be included in the
program plan for every new program. Conditionally required checkpoints may not be necessary
Process Primer Example/Exercise
Page 1 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
for certain programs. However, if a conditionally required checkpoint is not included in a
program plan, a justification of that checkpoint's exclusion must be given in the checklist that is
part of the PDP.
4.
<<fact>>Copies of the PDP are maintained in the Technical Resource Library and are held by all
Lead Engineers and functional Engineering Managers.
ATTACHMENT
ATTACHMENT “A”: Process Flow Chart(see hard copy in Library).
Approved: I. B. Manager (signed)______________Date:
I.B. Manager, Executive Vice President
Engineering and Quality
Process Primer Example/Exercise
Page 2 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
ENGINEERING DEPARTMENT
PRODUCT DESIGN PLAN
Global Solutions Development
Anywhere, USA
Process Primer Example/Exercise
Page 3 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
Process Primer Example/Exercise
Page 4 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
POLICY
<<policy>>It is the Engineering Department policy that all engineering programs, contractual and
strategic, without distinction, be done in accordance with this plan. It is the responsibility of the
appropriate functional Engineering Manager and the Lead Engineer to assure that this plan is followed,
and that the applicable checkpoints are included in their program plans. It is also their responsibility to
assure that cross–functional participation is facilitated for all aspects of the product design and that
concurrence with the program plan is obtained from the Program Manager through the Lead Engineer.
<process-tailoring guidelines>The checkpoints included in the plan are divided into two groups: required
and conditionally required. Required checkpoints must be included in the program plan for every new
program. Conditionally required checkpoints may not be necessary for certain programs. However, if a
conditionally required checkpoint is not included in a program plan, a justification of that checkpoints's
exclusion must be given in the checklist that is part of the PDP.
Approved: I.B. Manager (signed)_____________ (Date): _____
Process Primer Example/Exercise
Page 5 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
TABLE OF CONTENTS
section
1.
INTRODUCTION
1
2.
MISSION STATEMENT
2
3.
PRODUCT DESIGN PLAN (PDP) GUIDELINES
3
4.
PRODUCT DESIGN PLAN APPLICABILITY
4
5.
PRODUCT DESIGN PLANNING
5
THE PROCESS
CHECKPOINTS
GUIDELINES
6.
5.1
5.2
5.3
CHECKPOINTS: PROPOSAL PHASE (REQUIRED)
SPECIFICATION REVIEW
PROPOSAL CONCEPT SELECTION
SYSTEM ARCHITECTURE
DESIGN OBJECTIVES/SPECIFICATION REQUIREMENTS
QUOTATION ESTIMATE PROCESS (QEP)
DESIGN & TESTING PLAN/SCHEDULE
PROPOSAL TECHNICAL REVIEW
RISK ANALYSIS/MANAGEMENT
MANUFACTURABILITY
7.
8.
CHECKPOINTS: PROPOSAL PHASE
(CONDITIONALLY REQUIRED)
6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
7
LIFE CYCLE COST ANALYSIS (LCCA)
MAINTENANCE CONCEPT
ENVIRONMENTAL QUANTIFICATION REPORT
HISTORICAL RELIABILITY DATA REVIEW
HISTORICAL RELIABILITY DATA CHECKLIST
STANDARD APPLICATIONS REVIEW
7.1
7.2
7.3
7.4
7.5
7.6
CHECKPOINTS: DESIGN PHASE (REQUIRED)
TRANSITION TO PROGRAM
DESIGN OBJECTIVES/SPECIFICATION REQUIREMENTS
8
8.1
8.2
Process Primer Example/Exercise
Page 6 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
PRELIMINARY DESIGN/ANALYSIS/TEST
PRELIMINARY DESIGN REVIEW
DETAIL DESIGN/ANALYSIS/TEST
DETAILED ANALYSIS AND SIMULATION
DESIGN-TO-COST
MANUFACTURABILITY ANALYSIS
DEVELOPMENTAL TESTING
DESIGN FOR PRODUCT SAFETY
FINAL DESIGN REVIEW
9.
CHECKPOINTS: DESIGN PHASE
(CONDITIONALLY REQUIRED)
9
DESIGN FOR RELIABILITY, MAINTAINABILITY,
HUMAN FACTORS (RMH)
TESTABILITY ANALYSIS
TOLERANCE/MARGIN STUDIES
RENEWAL PARTS ANALYSIS
RENEWAL PARTS ANALYSIS CHECKLIST
LOGISTICS SUPPORT ANALYSIS (LSA)
LONG LEAD ITEMS
TRADE STUDIES
CUSTOMER DESIGN REVIEW
O&M MANUAL INFORMATION
10.
CHECKPOINTS: PROTOTYPE/
MANUFACTURE PHASE (REQUIRED)
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
10
PRODUCTION PROTOTYPE DOCUMENTATION PACKAGE
PRODUCTION PROTOTYPE
DESIGN VERIFICATION TESTS
PRODUCTION PROTOTYPE FINAL REVIEW
FACTORY TESTING
PRODUCTION RELEASE
11.
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
CHECKPOINTS: PROTOTYPE/MANUFACTURE PHASE
(CONDITIONALLY REQUIRED)
PRODUCTION PROCESS VERIFICATION
ENVIRONMENTAL TEST
SYSTEM TEST
Process Primer Example/Exercise
Page 7 of 29
10.1
10.2
10.3
10.4
10.5
10.6
11
11.1
11.2
11.3
Copyright 2004, Carnegie Mellon University. All rights reserved.
PRODUCT CAPABILITIES
PROTOTYPE FIELD TESTS
12.
11.4
11.5
CHECKPOINTS: COMMISSION PHASE
(REQUIRED)
COMMISSION TESTS
CLOSE–OUT REVIEW
13.
12.1
12.2
CHECKPOINTS: COMMISSION PHASE
(CONDITIONALLY REQUIRED)
DEMONSTRATION TESTS
FIELD FEEDBACK/RELIABILITY DATA
DESIGN INFORMATION FILE (ENGINEERING DATA BASE)
14.
12
13
13.1
13.2
13.3
REVISIONS TO THE PDP MANUAL
14
Process Primer Example/Exercise
Page 8 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
LIST OF CHECKLISTS
Table 5-1: Proposal Phase Checklist For Programs
Table 5-2: Design Phase Checklist For Programs
Table 5-3: Prototype/Manufacture Phase Checklist For Programs
Table 5-4: Commission Phase Checklist For Programs
Table 6-1 Base Line Design Requirements
Process Primer Example/Exercise
Page 9 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
1. INTRODUCTION
It is the goal of The Company to achieve industry leadership and become the preferred supplier for
solutions and services worldwide. In order to attain that position, the objectives become:
 Customer Satisfaction
 Recognized Technology Leadership
 Relevant Standards registratin/compliance
 Company Shareholder Value Increase
The Product Design Plan will aid in achieving this goal by providing a framework that:
 Assures the quality of the product or service.
 Maintains a schedule consistent with customer and company needs.
 Minimizes the cost to the customer and The Company .
The Product Design Plan (PDP) is a systematic process for program identification, planning, execution,
and monitoring, to assure that the requirements and goals of the program are met through effective
utilization of The Company's and other supporting skills and resources. This process features the use of
checkpoints, all or some of which should be included in all engineering programs. It is intended that the
engineer's understanding and implementation of the process will result in a systematic design approach.
It is further intended that users will continually review and improve the PDP. This will assure that
priorities are set which will be consistent with Company policy, and will aid in achieving industry
leadership.
The Product Design Plan checkpoints are integrated into four distinct phases of the design process: the
Proposal Phase, the Design Phase, the Prototype/Manufacture Phase, and the Commission Phase. In
addition, a final checkpoint for program closure is used within the Commission Phase to emphasize the
need for Engineering support throughout the life of the program. To facilitate implementation of the plan,
guidelines for each checkpoint have been developed. It is expected that systematic application of this
plan, along with sensible evolution of the guidelines, will result in highly productive design functions
which will converge on leadership in the transit industry.
Process Primer Example/Exercise
Page 10 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
2.
MISSION STATEMENT
The Product Design Plan supports the Engineering Department mission statement, which is:
Global Solutions Development Engineering provides the transformation of information and creative
knowledge by motivated associates into products, processes and sevices that result in customer
satisfaction, competitive advantage and company value.
Process Primer Example/Exercise
Page 11 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
3.
PRODUCT DESIGN PLAN (PDP) GUIDELINES
A.
<<policy>>This Product Design Plan (PDP) shall be incorporated into all new engineering
programs and design related activities. The extent of incorporation into existing programs shall be
determined by the appropriate functional Engineering Manager, Lead Engineer, and Program
Manager.
B.
<<policy>>The PDP process flow described in Section 5 shall be the basis for planning each
program.
C.
<<policy>>The PDP will provide for the implementation of a concurrent design process through the
use of a system of checkpoints to assure that the process is on target through all phases of the
product life cycle, including contract closure.
D.
<<policy>>The list of applicable checkpoints for each program phase shall be defined jointly by the
appropriate functional Engineering Manager, Lead Engineer and Program Manager.
E.
<<policy>>Each Resultant Program Phase checklist will contain a basic set of checkpoints which
are required by policy, and, in addition, each checklist will contain other “design practice"
checkpoints for consideration. Exclusion of any of these latter checkpoints must be justified.
Applying other checkpoints is at the discretion of the Lead Engineer and the appropriate functional
Engineering Manager.
F.
<<policy>>The guidelines and referenced procedures given in Section 6 through 12 are to be used
to implement the checkpoint review.
G.
<<policy>>Assigned Engineering department staff managers must approve the original PDP and
any revisions requiring the deletion or alteration of check points.
Process Primer Example/Exercise
Page 12 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
4.
PRODUCT DESIGN PLAN APPLICABILITY
<<policy--tailoring guidance>>The Product Design Plan incorporates a process which is generally
applicable to all programs regardless of contract scope or complexity. For major component programs,
the plan is directly applicable. For strategic programs, the activities/functions identified in the proposal
stage of the process flow are generally applicable for concept development, including a product
specification, as well as obtaining program cost estimates via the product cost estimation process.
For more complex programs, a sensible partitioning into an architecture of major subsystems will
facilitate the implementation of the plan. In this case, a composite of major component PDPs would be
integrated to achieve a system plan.
The depth of application of the PDP is affected by many factors, including:
A.
Customer requirements
B.
Safety related aspects of the design
C.
Complexity of design
D.
State of development of the technology
E.
Degree of duplication of a proven design (system, subsystem, or component)
F.
Program cost and schedule
The Product Design Plan is to be applied to both customer order programs and internal strategic programs
without distinction.
The Lead Engineer and the appropriate functional Engineering Manager must jointly decide on depth of
applicability for each major system element/component consistent with the committed budgetary
estimates.
Process Primer Example/Exercise
Page 13 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
5.
PRODUCT DESIGN PLANNING
The major steps of the Product Design Plan are shown on the Process Flow Chart(s) below. The
following notes are added for clarity.
5.1 : THE PROCESS
<<fact>>The overall process is accomplished in four phases. These are:
A.
The proposal phase
B.
The design phase
C.
The prototype/manufacture phase
D.
The commission phase
The operation phase of the system life cycle is not treated separately in the Product Design Plan. Field
operations reliability and performance data are used concurrently throughout the four phases of the
process.
Utilizing concepts of concurrent engineering, each phase embodies its own process flow. The sequence
of engineering functions at the top level are shown in bold print. A set of related activities is shown
within each functional block. These activities, when combined with the guidelines given in the following
related section constitute the baseline product design plan for each phase.
5.2 : CHECKPOINTS
<<policy—tailoring guidance>>In the flow chart, not all activities are necessarily required. This would
be the case with repeat business, for example. Conversely, some activities not shown might be required
by customer specification. For this reason, each plan is made unique by the selection of checkpoints for
each phase by the Lead Engineer and the functional managers. The checklists of check points to be
completed for each phase are given in tables 5-1 to 5-4 of this plan. Each checklist identifies mandatory
check points, recommended check points, and space for newly identified check points.
The purpose of mandatory checkpoints is to assure that a core design process is implemented for the
system (or element) being considered. Mandatory check points require that the tasks be done either on
the current program or use the results from another program, provided the results are applicable and
included in the current program via design review.
Where the core design process for a system (or element) differs from that shown in the checklist, such as
in software design, appropriate modifications should be made.
Recommended checkpoints are optional, but exclusion must be justified as above or traceability to similar
programs/applications showing acceptable risk must be provided.
All checkpoints selected including new checkpoints must be jointly approved by the lead engineer, the
functional manager and the program manager.
The check points generally follow the process flow, and each check point is identified and traceable to a
guideline.
Process Primer Example/Exercise
Page 14 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
5.3 :GUIDELINES
Guidelines are provided for each check point. They are not procedures, but do contain good practice
recommendations, pointers to procedures and other supporting materials. As the plan is used, refinement
of guidelines is a certainty.
Process Primer Example/Exercise
Page 15 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
<<process>>Figure 5-1. Product Design Process Flow: Proposal Phase
Marketing and Customer Service Activities
to Solve Problems and Assist in Defining
Systems Quotable by The Company

Receive RFQ

Evaluate for Bid Decision
Establish the Proposal Team

Identify System Requirements

Select the Proposal Concept

Develop System Architecture

Proposal Leader

Specification Review

Failure Data Review


Program Manager

Definition of Deviations/Risks



Operations Representatives



Marketing Manager(s)


Lead Applications Engineer

Customer Needs
Analysis/Coordination
Company Requirements
Definition
Specification Review Meeting
Alternate Concept
Evaluation
Manufacturability

Other Selected CE
Disciplines

Standard Application
Review
Comment/Exception Review
Resolution
System Performance
Analysis (Initial)
Life Cycle Cost Analysis
(Initial)
Maintenance Concept
Establish Material and Labor
Cost Targets
Trade Studies/Risk Analysis


Intellectual Property Review
Concept Design Review






Define System/Element Work
and Complete QEP


Requirements Summary
Element Task Descriptions

Manpower Estimates





Program Schedules
Outside Pricing Support
Cognizant Engineer Review
Completed QEP Sign-Off
Evaluate Cost Versus CAC
for Similar Contracts

Provide Proposal Write-up
Technical Support


Proposal Write-Ups/Figures
Proposal Format Development
Support

Complete Design and Test Plan
Schedules




Define Baseline Requirements/
Objectives For WBS Elements

Refine System Level Analysis

Interface Requirements

Top Down Definition of
System Elements
Assign WBS ID Numbers from
Standard List
Issue WBS

Functional Requirements

Create Operating Costing BOM

Environmental Requirements

Manufacturability

RMSH Requirements

Design-to-Cost


Verify Use of Standard Elements
Contract Commonality
Assessment
Manuals and Training
Requirements


Identify Milestones
Evaluate Element Tasks and
Manpower Loading Effects
Evaluate Design/Test
Related WBS Impact
Conduct Final Proposal Technical
Review





Process Primer Example/Exercise
Page 16 of 29
Review of Architecture
Review of Required
Checkpoints
Resolution of Comments/
Exception/Risks
Costs/Schedule Review

Senior Staff Cost/Price Review

Copyright 2004, Carnegie Mellon University. All rights reserved.
Figure 5-2. Product Design Process Flow: Design Phase
Receive Notice to Proceed

Enter order

Set Program Team











Program Manager
Lead Engineer
Functional Manager
Cognizant Engineer(s)
Functional Engineer(s)
System Engineer(s)
Manufacturing Engineer
Field Engineer
Marketing
Purchasing
Drafter
Conduct Preliminary Design
Review (PDR)
 Transition to Program


Information Package
Transition Reviews


Customer Interface
Meeting
 Establish Objectives/ Requirements
for System/LRUs










Task Assignment
Update Task Description
Information for O&M Manuals
Initiate Task Folders
Finalize System
Requirements
Customer Needs Analysis
CE Gated Checkpoints
Project Schedule Requirements
Standardization Objectives
 Product Design/Analysis/Test For Alternate Configurations












 Complete Detail Design/Analysis/Test for Selected Concept

Trade Study Results

System Details






Requirements
Supporting Technical Data
Customer Participation
Buy-off on Selected
Concept






Software Coding
Interface Design
Testability Design
Long Lead Disposition
Design-to-Cost
Development Prototype Tests




Specification Extreme Verification
Test
Malfunction/Off Normal Tests
Updated Simulations
Updated RMSH Studies
Updated Manufacturability Studies
Process Primer Example/Exercise
Page 17 of 29
Analytical Models
Bread Boards
Tolerance/Margin Studies
System Performance
Analysis
Testability Analysis
RMSH Studies
Safety Studies
Logistic Support
Analyses (LSA)
Renewal Parts Analyses
Software Structure













Manufacturability
Analysis (DFMA)
Design-to-Cost
Standard Design
Applicability
Simulation
Models/Testing
Materials Testing
Vendor Tests
Preliminary
Development Tests
Informal Design Reviews
Trade Studies
 Conduct Final Design Review


Customer Participation
Final Analysis/Test Data




Closure of PDR Items
Review Completed Drawings/Test Specifications
Reconcile PDR Versus FDR Configuration
Manufacturing Process Review

Copyright 2004, Carnegie Mellon University. All rights reserved.
Figure 5-3. Product Design Process Flow: Prototype/Manufacture Phase
Final Design Review

Complete Manufacturing
Documentation Package








Fabricate Production
Prototype

Test/Inspect
(FA)

Complete Prototype Design Verification
Tests









Signed Off Drawings,
Test Specifications
Software Documentation
O&M Manual
Information
Manufacturing Process
Conduct Production
Prototype Review





Product First Article

Conduct FAI
Review Test Results
Resolve Anomalies
Assure Final
Documentation
Release for Production
Update O&M
Information
Process Primer Example/Exercise
Page 18 of 29
Manufacturability Verification
Environment Tests
Maintainability Verification Tests
Factory Tests
System Tests
Field Tests
Product Capability
Documentation
Design Book Update

Produce Deliverables

Copyright 2004, Carnegie Mellon University. All rights reserved.
Figure 5-4. Product Design Process Flow: Commission Phase
Produce Deliverables

Ship/Install

Perform Commission Tests

Perform Demonstration
Tests


Customer Static Tests
Customer Track Tests



Company Tests


Special Test Equipment
Verification
Reliability Tests
Maintainability
Verification Tests
Availability Verification
Tests
Process Primer Example/Exercise
Page 19 of 29

Close-Out Review


Reconcile Open Items
Warranty Support

Review Field Feedback Data

Engineering Data Base
Copyright 2004, Carnegie Mellon University. All rights reserved.
Table 5-1: Proposal Phase Checklist For Programs
Proposal Phase Checkpoints
Specification Review
Program Plan
Status (In/Out)
In
Proposal Concept Selection
In
System Architecture
In
Design Objectives/Specification
Requirements
In
Quotation Estimation Process
(QEP)
In
Design and Testing Plan/Schedule
In
Proposal Technical Review
In
Risk Analysis/Management
In
Manufacturability
In
Life Cycle Cost Analysis
Maintenance Concept
Environmental Quantification
Report
Historical Reliability Data Review
Standard Applications Review
Process Primer Example/Exercise
Page 20 of 29
Justification
Copyright 2004, Carnegie Mellon University. All rights reserved.
Table 5-2: Design Phase Checklist For Programs
Design Phase Checkpoints
Transition to Program
Program Plan
Status (In/Out)
In
Design Objectives/Requirements
In
Preliminary Design/Analysis/Test
In
Preliminary Design Review
In
Detail Design/Analysis/Test
In
Analysis and Simulation
In
Developmental Testing
In
Design for Product Safety
In
Final Design Review
In
Design To Cost
In
Manufacturability Analysis
In
Reliability/Maintainability/Human
Factors Studies
Testability Analysis
Tolerance/Margin Studies
Renewal Parts Analysis
Logistic Support Analysis
Long Lead Items
Trade Studies
Customer Design Review
O&M Information
Process Primer Example/Exercise
Page 21 of 29
Justification
Copyright 2004, Carnegie Mellon University. All rights reserved.
Table 5-3: Prototype/Manufacture Phase Checklist For
Programs
Prototype/Manufacture Phase
Checkpoints
Production Prototype
Documentation Package
Program Plan
Status (In/Out)
In
Production Prototype (FA)
In
Design/Verification Tests
In
Production Prototype Review
In
Production Release
In
Factory Tests
In
Production Process Verification
Environmental Tests
System Tests
Field Tests (Prototype)
Product Capabilities
Process Primer Example/Exercise
Page 22 of 29
Justification
Copyright 2004, Carnegie Mellon University. All rights reserved.
Table 5-4: Commission Phase Checklist For Programs
Commission Phase Checkpoints
Commission Tests
Program Plan
Status (In/Out)
In
Close Out Review
In
Demonstration Tests
Field Feedback/Reliability Data
Design Information File
Process Primer Example/Exercise
Page 23 of 29
Justification
Copyright 2004, Carnegie Mellon University. All rights reserved.
6.
CHECKPOINTS: PROPOSAL PHASE
(REQUIRED)
6.1 : SPECIFICATION REVIEW
Definition
<<concept>>A review of each section of the specification to identify
possible exceptions, nonconformances and/or unusual requirements as
well as to assure complete requirements definition, such as for operating
environment.
Purpose
To identify possible exceptions, evaluate risks and to firm application
and costing strategies for areas of uncertainty.
Guidelines
<<policy??procedure??>>The proposal team, with assistance from
affected disciplines, should review each section of the specification to
identify requirements which are candidates for exception and/or risk
assessment, and establish appropriate costing strategies.
Use the guidelines in Engineering Proposal Process procedure to
document and coordinate the review, including the specification review
meeting.
The Lead Applications Engineer should coordinate review comments for
the engineering disciplines.
Documentation
Provide a summary review report which cites sections reviewed, risk
analyses and recommendations made.
References
Engineering Proposal Process
Process Primer Example/Exercise
Page 24 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
6.2: PROPOSAL CONCEPT SELECTION
Definition
Selection of the elements which comprise the system to be proposed.
Purpose
To establish the baseline concept for bidding purposes.
To identify possible exceptions, evaluate risks and to firm strategies for
areas of uncertainty.
Guidelines
Work with the proposal team to resolve any issues arising from the
specification review and evaluate risks prior to final selection.
Complete a preliminary performance and reliability history review.
Utilize Cognizant Engineers and Logistics Engineers to retrieve, evaluate
and maintain a performance history data base.
In cooperation with marketing and the cognizant design engineers,
Applications Engineering should define other concepts which potentially
meet requirements, particularly where standard components might not be
applicable.
Perform initial Life Cycle Cost Analyses to assess the “design to cost"
potential for each alternate (perform acquisition cost analyses at a
minimum).
Perform initial manufacturability analysis.
Complete initial trade studies based on at least the costs, performance,
schedule, reliability, safety and operational availability.
Achieve general agreement with Marketing and Program Management
prior to further development of the overall Quotation Estimate Process
(QEP) for the selected concept, via conceptual review meetings.
Documentation
The Lead Applications Engineer should publish a baseline system
definition to be used as the top level for system architecture
development.
References
EDP–P10 Engineering Proposal Process
CP–PP1
Proposal Preparation
Process Primer Example/Exercise
Page 25 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
6.3: SYSTEM ARCHITECTURE
Definition
A structured representation of the way in which the components,
modules, subsystems, software, etc., that comprise the overall system are
organized, configured, and integrated such that the overall system
requirements are met.
Purpose
To provide a structured approach that defines the equipment and
software that will meet or exceed the customer specification and
Company internal requirements.
Guidelines
The system architecture applies to both hardware and software based
systems.
Use the baseline proposal concept to develop the system architecture in
detail.
Identify all lower tier system elements down to the level consistent with
the standard work breakdown structure (WBS) and assign appropriate
WBS identifiers. Where required, provide a similar breakdown for all
non-hardware system elements, including computer software and other
system support deliverables. Publish the WBS for use in the proposal
process.
Documentation
Publish the work breakdown structure. Record and retain all input,
output and other interface data for use in developing design
requirements.
References
“Structured Analysis and System Specification", by Tom DeMarco,
Yourdon Press, 1979.
Engineering Proposal Process
Proposal Preparation
Standard Work Breakdown Structure
Process Primer Example/Exercise
Page 26 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
6.4 : DESIGN OBJECTIVES/SPECIFICATION REQUIREMENTS
Definition
The functional and design criteria established for each component in the
proposal phase during the creation of the system architecture.
Purpose
To provide a clear and documented definition of the requirements to be
used in the proposal and the following design phases.
Guidelines
All requirements should be considered concurrently to assure that lower
tier requirements are completely developed from the start.
Use output of structured analysis done for system architecture, i.e. the
WBS, as the baseline for defining requirements.
Prepare a preliminary design objectives document for each major
component and its lower tiered elements as defined in the WBS.
Use the complete customer contract document, including the technical
specification, terms and conditions, and other special provisions to trace
and define requirements.
Include general customer requirements such as material and
environmental requirements, codes and standards, water tests, CDRL
items, etc., as well as requirements specific to a component. Check the
section on system support for any special requirements for manuals and
training.
Include internal design objectives not specified by the customer, such as
interface requirements, product cost, and manufacturability.
Consider the use of the design on future orders when setting objectives.
Consider the impact of using a current standard design. Refer to the
appropriate “cognizant engineer design book" in evaluating applicability.
Design objectives should include criteria to be satisfied for the
checkpoints to be met in the project's later phases, including:













Detailed Analysis and Simulation
Reliability, Maintainability and Human Factors Study
Product Safety Analysis
Tolerance/Margin Study
Design–to–Cost Objectives, including engineering hours scheduled,
as well as total product costs.
Milestones, Schedules
Logistics Support Analysis
Manufacturability Analysis
Testability Analysis
Design Verification Test
Environmental Factors and Testing
System Test
Product Capabilities
Process Primer Example/Exercise
Page 27 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
 Commission Test
 The Use of Standard Components/Subsystems/Systems
Summarize the requirements definitions and sources as shown typically
on Table 6-1. Where requirements are special or an exception is to be
taken, the requirement should be detailed sufficiently on Table 6-1 to
assure special consideration in the estimation process; otherwise, the
requirement is understood to be within normal expectations for transit
industry applications.
All exceptions to the contract specifications and all special requirements
are to be reconciled prior to sign–off of the estimate.
Additional items discovered while completing the estimate should be
added to Table 6-1.
The documented requirements (Table 6-1) are to be attached to the
estimate and used as a basis for developing detail work statements for
later use in task folders as well as for current proposal pricing.
Documentation
Complete Table 6-1 and integrate with estimates during proposal phase.
Update with any changes developed during negotiations and use as the
baseline for task folders at the start of the design phase.
The Lead Engineer is responsible for ensuring that this information is
documented.
References
Engineering Task Folders
Cognizant Engineer Design Books
Quotation Estimate Process Procedure
Design–to–Cost Guideline
Process Primer Example/Exercise
Page 28 of 29
Copyright 2004, Carnegie Mellon University. All rights reserved.
TABLE 6-1 BASE LINE DESIGN REQUIREMENTS
DATA
Reference
(Specification Section
or Other)
Parameter
Special
Requirements/Comments
NOTES:
A.
For all major components, list all requirements, references and parameters.
B.
Identify only special requirements; otherwise “Normal" (N).
C.
For lower tier elements, cite major component WBS and record only any other
additional requirements.
D.
This list merely identifies the requirements and the sources. The design must
ultimately satisfy the customer contract specifications.
Process Primer Example/Exercise
Page 29 of 29