1

Chapter 4.4 (pages 91-101)

Four basic steps

Requirements analysis clarify about what we want

Functional definition identify technical purposes
Physical definition create the solution (output)
Design validation check the solution (output)

These four steps are applied repeatedly in

Needs analysis (chapter 6)
Concept exploration (chapter 7)
Concept definition (chapter 8)

These steps vary in their specifics depending on

the type of system and the phase of its
development

Focus on the input and

output
This is the basic
procedure that needs to
be memorized.

Requirements Analysis

Operational Requirements
Analysis

Understand the operational

requirements
Identify and resolve
problems with the
operational requirements
Conflicts
Incomplete requirements
Obviously
expensive/impossible

Provide feedback to the

users
Request clarifications
Recommend changes

Assemble and organize all input conditions

Identify the whys of all requirements in
terms of operational needs, constraints,
environment or other higher-level objectives
Clarify the requirements of what the system
must do, how well it must do it, and what
constraints it must fit
Correct inadequacies and quantify the
requirements wherever possible
Essence of quantify: make things be more
specific and tangible.
9

Functional Definition
Determine System
requirements
Go to 1st subsystem level
if needed

Determine required
performance
Define top level scope of
system

10

Translate requirements (why) into functions (actions

and tasks) that the system must accomplish (what)
Partition (allocate) requirements into functional
building blocks
Define interactions among functional elements to lay
a basis for their organization into a modular
configuration
Insight: similar to (not the same as) the practice of
Quality Function Deployment (QFD)
The distinctions among objectives, requirements and
functions are tedious.
Objective tends to be at higher level
Requirement tends to be more technical with various
types
Function context of functional build blocks

11

Physical Definition

Define candidate
implementation concepts
(solutions)
Define functions
Assign to candidate
subsystems
Define necessary subsystem
requirements and
performance characteristics

Provide feedback to
Functional Definition
System requirements need
to change?

12

Synthesize a number of alternate system

components representing a variety of design
approaches to implementing the required
functions
Define the most simple practicable interactions
and interfaces among structural sub-divisions
Select a preferred approach by trading off a set
of predefined and prioritized criteria (measures
of effectiveness [MOE]) to obtain the best
balance among performance, risk, cost and
schedule
Elaborate the design to the necessary level of
detail

13

Design Validation

Validate Requirements
Ensure requirements are
consistent and complete
Ensure concepts are
feasible

Provide feedback to Design

Implementation
Correct deficiencies in
candidate concepts
Change system
requirements
Recommend changes to
operational requirements

14

Design models of the system environment

reflecting all significant aspects of the
requirements and constraints

Types of models: logical, mathematical, and physical

Simulate or test and analyze system solution(s)

against environmental models (via scenarios)
Iterate as necessary to revise the system model
or environmental models, or to revise system
requirements if too stringent for a viable solution
until the design and requirements are fully
compatible
Key: check the solution via experimentation on
models

15

16

17

Concept Exploration
Definition of operational requirements
Functional analysis and formulation

Concept Definition
Definition of performance requirements
Functional allocation

Concept Selection and Validation

18

Definition of operational requirements (p. 145)

Mission and purpose of the system
Describe and communicate the end state of the world

Operational requirements analysis (chapter 7.2)

Requirements elicitation
Users and operators (via market survey and interviews)
Subject matter experts
Previous studies and system development efforts

Requirements analysis
Check if the requirements are valid, feasible, vague or
inconsistent
Avoid any redundant requirements

19

Recall the functional building blocks

Functions:

How to identify system functions

Help to interpret the information of operational and performance

requirements with more engineering contents
Help to explore different system concepts
Functional media: signals, data, material and energy
Ask the questions (next slide)
Three function categories: input, transformative and output

Input function: the processes of sensing and inputting

functional media into the system
Output function: the processes of interpreting, display,
synthesizing and output functional media out of the
system
Transformative function: transforming inputs to outputs

20

Are there operational objectives that require sensing

or communications?
If so, this means that signal input, processing, and output
functions must be involved.

Does the system require information to control its

operation?
If so, how are data generated, processed, stored, or
otherwise used?

Does system operation involve structures or

machinery to house, support, or process materials?
If so, what operations contain, support, process, or
manipulate material elements?

Does the system require energy to activate, move,

power, or otherwise provide necessary motion or
heat?
21

High-level system block

22

Definition of performance requirements (p. 145)

How well the system should perform its requirements
and affect its environment
Provide numerical thresholds (should be objective and
quantitative)

System performance characteristics (p. 191)

Define what the system must do, and how well, but not
how the system should do it
Define characteristics in engineering terms that can be
verified by analytical means or experimental tests
If a system possesses the stated characteristics, it will
satisfy the operational requirements

23

Developing functional building blocks (p.

207)
Identification of functional media
Identification of functional elements (p. 47)
Relation of performance requirements to element
attributes
Configuration of functional elements
Analysis of integration of all external interactions

Functional block diagramming tools (p. 209)

A representation tool for better communication
E.g., functional block diagram, IDEF, etc
24

Source: pages 181-182, 209-210

Step 1: identify the necessary inputs

Signals: user commands

Data: none
Material: fresh coffee grinds, filter, and water
Energy: electricity
Forces: mechanical support

Signals: status (on or off, coffee done or not)

Data: none
Materials: brewed coffee, used filter, used coffee grinds
Energy: heat
Forces: none

Step 2: identify the outputs

25

Remark: the functions confine what to look at

for the system

How do we transform fresh coffee grinds, a filter, water,

and an on/off command into brewed coffee, a used
filter, used coffee grinds and a status?

Input functions: accept user command, receive

coffee materials, distribute electricity, distribute
weight
Transformative functions: heat water, mix hot
water with coffee grinds, filter out coffee grinds,
warm brewed coffee
Output functions: provide status, facilitate
removal of materials, dissipate heat

26

Accept water
Accept Coffee Grounds
Accept filter
Accept power setting
Display power setting
Produce heat
Make coffee
Keep coffee warm

27

Accept water

Input water
Store water

Accept Coffee Grounds

Convert electricity to heat

Accept filter

Input filter
Remove filter

Accept user input

Turn electricity on/off

Display power setting

Sense power usage

Illuminate power indicator

Make coffee

Transport water from storage

Heat water
Filter water through ground
coffee
Send coffee to coffee storage

Input coffee grounds

Remove coffee grounds

Accept power setting

Produce heat

Keep coffee warm

Store coffee
Transfer heat to coffee to
keep warm
Remove coffee

28

29

Source: chapter 8.4

Allocation of functions to physical components of
the system (p. 212)
It can be viewed as concept formulation

Decision on functions decision on physical

components affect the following two issues
System measures: ultimate performance, cost, etc
Who will develop the system (supplier selection)

Modularity issue (pages 212-213)

Multiple functions single physical component or a

single function multiple sub-systems
Ideal: one-to-one mapping modular structure

30

Predecessor system as a baseline

Technological advances

Focus on the deficient components or sub-systems

Minimize the modifications
System upgrade: same function improved component
Possibility of a radical departure from the existing
system
Be aware of the risks such as deliverable of new
technology, cost and time

Original concepts: relatively rare

Output

Functional block diagram (or FFBD)

Pictorial or other physical description produced for
providing a more realistic view of the system candidate

31

Source: chapter 8.5-8.6

Trade-off analysis
Assessment of goodness degrees
Achieve the balance among different goodness
measures

Goodness measures
Operational performance and compatibility
Program cost and schedule
Risk in achieving each of the above

32

Design margins

Program risks

Selection strategy: guidelines for trade-off

Referred to the amount that a given system parameter

can deviate from its nominal value without producing
unacceptable behavior of the system as a whole
Similar concept: robustness
Probability of failure + criticality of failure

Conserve analytical effort, use a staged approach to the

selection process, in which only the most likely winners
are subjected to the full system evaluation
Retain the visibility of the complete evaluation profile of
each concept (rather than combining the measures into
one merit)

33

Car 1
Fuel efficiency = 10 km/L (Goodness score = 7)
Cost = $10,000 (Goodness score = 8)
Total score = 15

Car 2
Fuel efficiency = 12 km/L (Goodness score = 9)
Cost = $12,000 (Goodness score = 7)
Total score = 16

If we just look at the total scores, we may

lose the overall picture.

34

Critical experiments

Obtain sufficient data to understand thoroughly the

behavior of the system element
Stress the proposed design feature to its extreme
limits to ensure that it is not just marginally
satisfactory

At the conceptual stage, validation can be a

piece of arguments with some evidence
(based on existing systems)
The feedback from validation can lead to
some development iterations for refining and
improving the system models

35

Customer

Surveys & Feedback, Marketing Data

Related Designs

Specs & Drawings for previous versions

Similar designs of competitors

Analysis Methods

Handbooks, Textbooks, Monographs, Technical

Reports, Specialized computer programs

Materials

Performance in past designs, Properties

Manufacturing

Capability of Processes, Capacity analysis

Manufacturing sources, Assembly methods

Cost

Cost history, Current material & manufacturing

costs

Standard Components

Availability & Quality of vendors, Size & Technical

Data

Technical standards

ISO, ASTM, Company specific

Governmental
Regulations

Performance-based, Safety requirements

Life Cycle issues

Maintenance/service feedback,
Reliability/quality/warranty data
36

Libraries

Dictionaries, engineering handbooks, texts, periodicals

Internet

A massive depository of information

Government

Technical reports, databases, agency-based search

engines, laws & regulations

Engineering
professional
societies & trade
associations

Technical journals & news magazines, Technical

conference proceedings, Codes & standards

Intellectual property

Patents, Copyrights, Trademarks

Personal activities

Buildup of knowledge, Contacts with colleagues, Personal

network, contacts with suppliers & vendors, Attendance f
conferences, Visits of other companies

Customers

Direct involvement, Surveys, Feedback from warranty

payments
37