Engineering Department Procedure

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
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
ENGINEERING DEPARTMENT
PRODUCT DESIGN PLAN
Global Solutions Development

Anywhere, USA
Process Primer
Example/Exercise
Page 3 of 29
Process Primer
Example/Exercise
Page 4 of 29
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 crossfunctional 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
TABLE OF CONTENTS
section
1.
INTRODUCTION
2.
MISSION STATEMENT
3.
PRODUCT DESIGN PLAN (PDP) GUIDELINES
4.
PRODUCT DESIGN PLAN APPLICABILITY
5.
PRODUCT DESIGN PLANNING
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
8
8.1
Process Primer
Example/Exercise
Page 6 of 29
DESIGN OBJECTIVES/SPECIFICATION REQUIREMENTS

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

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.
11.
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
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
10.1
10.2
10.3
10.4
10.5
10.6
CHECKPOINTS: PROTOTYPE/MANUFACTURE PHASE

11
PRODUCTION PROCESS VERIFICATION

ENVIRONMENTAL TEST
Process Primer
Example/Exercise
Page 7 of 29
11.1
11.2
SYSTEM TEST
PRODUCT CAPABILITIES
PROTOTYPE FIELD TESTS
12.
11.3
11.4
11.5
CHECKPOINTS: COMMISSION PHASE

(REQUIRED)
COMMISSION TESTS
CLOSEOUT REVIEW
13.
12.1
12.2
CHECKPOINTS: COMMISSION PHASE

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
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
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 registration/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
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
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
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
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
<<policytailoring 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
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

<<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)
Standard Application Review
Lead Applications Engineer
Customer Needs
Analysis/Coordination
Company Requirements
Definition
Specification Review Meeting
Alternate Concept
Evaluation
Manufacturability
Other Selected CE
Disciplines
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
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)
Trade Study Results

Requirements
Supporting Technical Data
Customer Participation
Buy-off on Selected
Concept
Transition to Program
Information Package
Transition Reviews
Customer Interface
Meeting
Establish Objectives/ Requirements

for System/LRUs
Product Design/Analysis/Test For Alternate Configurations
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
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
Complete Detail Design/Analysis/Test for Selected Concept
System Details
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
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
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
Manufacturability
Verification
Environment Tests
Maintainability Verification
Tests
Factory Tests
System Tests
Field Tests
Product Capability
Documentation
Design Book Update
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
Produce Deliverables
Figure 5-4. Product Design Process Flow: Commission Phase
Produce Deliverables
Ship/Instal
l
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
Close-Out Review
Reconcile Open Items

Warranty Support
Review Field Feedback

Data
Engineering Data Base
Process Primer
Example/Exercise
Page 19 of 29
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
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
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
Table 5-3: Prototype/Manufacture Phase Checklist For

Programs
Prototype/Manufacture Phase
Checkpoints
Program Plan
Status (In/Out)
Production Prototype
Documentation Package
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
Table 5-4: Commission Phase Checklist For Programs
Commission Phase Checkpoints
Program Plan
Status (In/Out)
Commission Tests
In
Close Out Review
In
Demonstration Tests
Field Feedback/Reliability Data
Design Information File
Process Primer
Example/Exercise
Page 23 of 29
Justification
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
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
EDPP10 Engineering Proposal Process

CPPP1
Proposal Preparation
Process Primer
Example/Exercise
Page 25 of 29
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
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
DesigntoCost Objectives, including engineering hours scheduled,
as well as total product costs.
Milestones, Schedules
Logistics Support Analysis
Manufacturability Analysis
Design Verification Test
Environmental Factors and Testing
System Test
Process Primer
Example/Exercise
Page 27 of 29
Product Capabilities
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 signoff 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
DesigntoCost Guideline
Process Primer
Example/Exercise
Page 28 of 29
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

Engineering Department Procedure

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Engineering Department Procedure

Transféré par

Droits d'auteur :

Formats disponibles

Copyright 2004, Carnegie Mellon University. All rights reserved.