1. SysEng 368 Systems Engineering Analysis I
Steven Corns
Requirements and Functional Analysis

2. Upcoming Milestones Upcoming deliverables/homework August 31th
Need statement should be finalized with the customer
September 11th
Customer agreement with system level (Tier 0) requirements – Feasibility Analysis

3. Twelve Worst Systems Engineering Transgressions
An over reliance upon a specific analytical method or tool, or a specific technology that is advocated by a particular group.

4. 2. A consideration of perceived problems and issues only at the level of symptoms, and the development and deployment of “solutions” that only address symptoms.

5. a) Identification of major pertinent issue formulation elements
3. A failure to develop and apply appropriate methodologies for issue resolution that will allow:
a) Identification of major pertinent issue formulation elements
b) A fully robust analysis of the variety of impacts on stakeholders and the associated interactions among the steps of the problem solution procedure
c) An interpretation of these impacts in terms of our institution and values

6. 4. A failure to involve the client, to the extent necessary, in the development of problem resolution alternatives and systemic aids to problem resolution.

7. 5. A failure to consider the effects of cognitive biases that result from poor information processing heuristics.

8. 6. A failure to indentify a sufficiently robust set of options, or alternative courses of actions.

9. 7. A failure to make and properly utilize reactive, interactive, and proactive measurements to guide the systems engineering efforts.

10. 8. A failure to identify risks associated with the costs and benefits, or effectiveness, of the system to be acquired, produced, or otherwise fielded.

11. 9. A failure to properly relate the system that is designed and implemented with the cognitive style and behavioral constraints that impact the users of the system, and an associated failure to properly designing the system for effective user interaction.

12. 10. A failure to consider the implications of strategies adopted in one of the three life cycles (RDT&E, acquisition & production, and planning & marketing) on the other two life cycles.

13. 11. A failure to address quality and sustainability issues in a comprehensive manner throughout all phases of the life cycle, especially in terms of reliability, availability, and maintainability.

14. 12. A failure to properly integrate a new system together with heritage or legacy systems that already exist and that the new systems should support.

15. 4. System Requirements Analysis
Operational Requirements
Maintenance and Support Requirements
Disposal Requirements

16. Operational Requirements
Operational Distribution or Deployment
Mission Profile or Scenario (ConOps)
Performance and Related Parameters
Utilization Requirements-Operational Profile

17. Operational Requirements
Effectiveness Requirements (FOMs, MOEs)
Operational Lifecycle – Time Horizon
Environment

18. Questions? What functions will the system perform?
When will the system be required to perform the function and for how long?
Where will the system be used?
How will the system accomplish its objective?
Who? Why?

19. Maintenance and Support Requirements
Levels of Maintenance
Where and What
Repair Policies
Repair or Replace and Disposal
Organizational Responsibilities
Who does what
Logistic Support Elements
Resources
Effectiveness Requirements
Maintenance & Support Oriented
Environment

20. Disposal Requirements
Material re-use/recycling
Hazardous Materials
Environmental and Personnel Safety
Public Safety

21. Technical Performance Measures
Qualitative and Quantitative Design Criteria
Lead to the Development of Design Dependent Parameters (DDP)
Established as Viewed by the Customer!
Quality Function Deployment (More Later)

22. Functional Analysis and Allocation
The iterative process of translating system requirements into detailed design criteria, along with the identification of specific resource requirements at the subsystem levels.
(More Later)

23. Synthesis, Analysis, Evaluation and Trade Studies
Synthesis – the combining and structuring of components in such a way as to represent a feasible system configuration.
Baseline configuration is developed in order to move into preliminary design!

24. System Specification System specification includes information from:
Feasibility Analysis
Operational Requirements
Maintenance and Support Concepts
Functional Analysis and Allocation
Documents Requirements—Not Solutions

25. System Specification
System specification includes the technical, performance, operational and support characteristics for the system as an entity.
It may include the allocation of requirements to functional areas, and it may define the various functional - area interfaces. This may also be done through segment or element level specifications and Interface Control Documents.
Will be a function of the system’s complexity
(Later)

26. Solving The Wrong Problem Or Finding the Right Problem

27. Recognizing the Wrong Problem
Each of us has solved the wrong problem from time to time
Context is always changing
Regularly seek out new information
Is it still the right problem?
Take action
“One way to maintain a hypothesis indefinitely
is to ignore information that does not conform to it.”
Dietrich Dörner, The Logic of Failure

28. Clues for Recognizing the Wrong Problem
No longer relevant
Users’ needs not satisfied
Avoiding the hard problems
Tool limitations
Technical
Group Think

29. No Longer Relevant Work products no longer relevant
Level of detail more than needed to answer the questions
Engineers continue to frame issues in terms of a previous project

30. Users’ Needs Not Satisfied
Validation of needs not adequate
Users do not believe their needs are being satisfied
Stakeholders with contrary views
Do not think it is the right problem
Not included

31. Avoiding the Hard Problems
“Low hanging fruit” instead of the more difficult problems

32. Process & Tool Limitations
Processes that cause important issues to receive inadequate attention
Processes that result in useless or excessive work
Tools that dictate the processes

33. Technical Cost or risk unacceptably high
Technical achievability in doubt
Problem reappears after supposedly solved
Subsystem engineers complain “they have to start work” even without requirements
Precisely correct problem is not solvable

34. Group Think Dissent frequently suppressed
Minimal diversity and quick consensus
Lack of discomfort with the problems and solutions

35. Shifting to the Better Problem
Personal gain
Excessively following the rules
Investment in what has already been accomplished
Extreme discomfort with ambiguity

36. Getting Closer to the Right Problem
Perfect articulation of the precisely right problem is usually the wrong problem
Being precise may not be relevant
“Right” problem is a moving target
Better problem is often more ambiguous and uncertain
There are well formulated problems with unambiguous boundaries. They are called classroom exercises.
Ian Mitroff, Smart Thinking for Crazy Times

37. Excessively Following the Rules
More unprecedented = more rules that may not apply anymore
Ambiguity blurs the rules
“To be successful, a planner must know when to follow established practice and when to strike out in a new direction.”
Dietrich Dörner in The Logic of Failure

38. Investment in What Has Been Done
Resistance to abandoning a poor solution
Pride of authorship
Sunk resources
Excuses fear of unknown

39. Extreme Discomfort with Ambiguity
Use standard methods
Functional decomposition
Physical decomposition
Integrated planning and scheduling
Work breakdown structure
Standard methods may not be sufficient
Augment with questions
Requires lots of hand holding
SE provides a structured approach for systematically reducing the uncertainties and ambiguities associated with developing products and services

40. There Is No Magic
Recognizing the wrong problem takes vigilance, patience, and persistence
Identifying the better problem is often approximate and iterative
Shifting to the the better problem may be more about personal comfort than technical concerns

41. Conceptual Design Review
Information to be provided separately.
Schedule with the Customer!!!

42. Then What? Preliminary Design Review Detail Design and Development
Production
Utilization and Support
Phase-out and Disposal

43. The Importance of Requirements The DOD Example
Department of Defense projects are progressively more costly—commercial products are rarely much more costly
F-15 ~ $30-40 Million
F-22 ~ $120 Million

44. The Importance of Requirements
Meanwhile, Personal Computer costs…

45. The Importance of Requirements The DOD Example
Department of Defense projects are progressively more costly—commercial products are rarely much more costly
Some of the why lies in the requirements
Requirements beyond the state of the art
Adding new technologies (requirements) during development
“We have to make sure we are controlling requirements.”
Gen. John P. Jumper USAF Chief of Staff

46. The Problem Continues
"The requirement guys want it to be a tanker, a cargo aircraft, a communications relay node and platform for collecting signals intelligence," the Air Force official says. "The lack of requirements discipline is a big, big mistake. It could make the aircraft unaffordable and technically unachievable."
From Aviation & Space Technology, 1/2/2006
USAF Space and Missile Command root causes of major system failures included:
Incomplete requirements flow down
Misleading requirements language
From D. Davis, GEIA SSTC meeting, January 2006

47. Requirements Development
Gathering
Functional decomposition and analysis
Derived requirements
Allocation
Validation
Finding a workable set
Verification

48. Requirements Management
Baselines and changes
Traceability
Documentation
Requirements quality
Consistency with project work

49. Why Do Requirements Development
Common understanding among users, developers, and acquirers about what is needed
Reduce risk for designing and implementing a successful solution to acceptable levels
Fill in the blanks among the needs and expectations
Discover the unstated expectations
Explain the context for using the product
Confidence that needs and expectations are being met (validation)

50. Why Do Requirements Management
Requirements are the basis for agreeing that a product has been completed successfully (or not)
Provide unambiguous requirements that are testable (verification)
Provide traceability so the impact of changes on requirements can be observed
Know what requirements apply to each subsystem
Show the completeness of the allocation
Assign Responsibility, Authority, and Accountability to requirements

51. It’s Not Easy - 1 Making the requirements unambiguous and not compound
Rooting out overlapping requirements
Keeping the traceability up to date
Producing the myriad of requirements “documents”
Gathering all the comments for making Configuration Change Board (CCB) decisions
Planning and implementing the evolving requirements baselines

52. Its Not Easy – 2 (difficulties)
Users provide only design solutions instead of operational requirements
“That won’t work!”
Insufficient resources
So many competing and contradictory requirements
Not sure what we want, but we’ll know it when we see it
So much uncertainty and ambiguity
Getting people to understand that “draft” requirement

53. Stakeholders May Not Articulate Needs Well
Narrowly focus on own problems rather than whole system
Use analogies with design
Think in terms of solutions rather than operational (functional) needs
Unstated needs
We can use ESP or we can work at eliciting needs

54. Keys To Success Quality of the writing of the requirements for:
Understanding the intent
Unambiguous verification
Traceability between requirements and system components
Excellent configuration management of the requirements
Clear Responsibility, Authority and Accountability for each requirement

55. Requirements Quality Quality criteria for individual requirements
Isolated
Concise
Unambiguous
Measurable
Verifiable
Feasible
Necessary
Sufficient

56. Isolated Requirements
Include or refer to bounded parameters
Measurability is essential for verifiability
Poor – Multiple Implied ‘shalls’
The ND shall provide expanded (sector) and center (full rose) map modes in accordance with Section 10.1.
Automatic direction finder (ADF) and ultra-high frequency (UHF) direction finder (DF) radio indications shall be available in both expanded and center map modes.
GOOD – Measurable
Expanded Map Mode
The ND shall provide expanded (sector) map mode in accordance with Section 10.1.
ADF and UHF DF radio indications shall be available for display in expanded map mode.
Center Map Mode
The ND shall provide center (full rose) map mode in accordance with Section 10.1.
ADF and UHF DF radio indications shall be available for display in center map mode.

57. GOOD – Concise, a Requirement not a Solution
Concise Requirements
Not weighed down by explanations, definitions, or other peripheral information
Poor – Too Much Stuff
The environmental control system, which is made up of the air conditioning, air heating, and pressure-monitoring systems and whose function is to maintain a cabin temperature of 23°C ±3°C (see DR paragraph (a-17)), shall be controllable from the cockpit.
GOOD – Concise, a Requirement not a Solution
The environmental control system shall be controllable from the cockpit.

58. Unambiguous Requirements
Free of words and phrases such as “reasonable,” “acceptable,” and “minimize”
Avoid nonspecific, unclear, or immeasurable terms
POOR – Ambiguous
The System Operating Cost shall be $100 per Operating Hour or better, where applicable.
GOOD – Unambiguous
The System Operating Cost, as defined and measured per D6-ABCDE, shall be no greater than $100 per Operating Hour.

59. Measurable Requirements
Include or refer to bounded parameters
Measurability is essential for verifiability
Poor – Not Measurable
The System Operating Cost shall be at least as good as the best of the current systems.
GOOD – Measurable
The system Operating Cost, as defined and measured per D6-GHKI, shall be no greater than $100 per Operating Hour.

60. Verifiable Requirements
Compound requirements are difficult to determine how to verify
POOR – Not Verifiable
Trip-free circuit breakers shall be used to prevent wire damage and to coordinate with other subsystem protective features. Circuit breakers located in the crew compartment shall be grouped by system and aligned by buses. They shall be protected from damage and accidental activation.
GOOD – Decomposed and Verifiable
Trip-free circuit breakers shall be used to prevent wire damage.
Trip-free circuit breakers shall be used to coordinate with other subsystem protective features.
Circuit breakers located in the crew compartment shall be grouped by system.
Circuit breakers located in the crew compartment shall be aligned by buses.
Circuit breakers shall be protected from damage.
Circuit breakers shall be protected from accidental activation.

61. Feasible Requirements
A technically achievable way to implement the requirement exists
Does not apply to requirements prior to establishing the baseline for the preferred concept during Concept and Technology Development.

62. Necessary Requirements
Unnecessary requirements cost money and effort
Two types
Unnecessary specification of design that should be left to the discretion of the designer
A redundant requirement covered in some other combination of requirements
Very hard to say that a set has no unnecessary requirements

63. Sufficient Requirements
Sufficient if needs are communicated; otherwise not sufficient
Very hard to say that a set of requirements is sufficient

64. Transform Needs Into Requirements
Functionality
How is it used?
What does it do?
Performance

65. Balancing Requirements
Transform into requirements that balance:
Needs
Achievability
Acceptable risks
Acceptable costs
Feedback Loops in the Process

66. Development and Management of Requirements and Concept Development
Step 1: Establish the Objectives for the Requirements Development Activities
Step 2: Identify and Collect Stakeholder Needs, Expectations, and Constraints
Step 3: Develop Scenarios (Operational Concepts)
Step 4: Define Issues About Requirements That Need Exploration
Step 5: Develop a Description of Desired Functionality
Step 6: Develop Requirements for Performance
Step 7: Allocate Requirements
Step 8: Develop Interface Requirements
Step 9: Develop Alternative Solutions
Step 10: Analyze Requirements
Step 11: Validate Requirements to Ensure the Resulting System Will Adequately Meet Stakeholder Needs
Step 12: Decide Whether the Current Path of Requirements Development Should Continue
Step 13: Establish and Maintain Requirements

67. Four Key Questions
Are the candidate requirements likely to lead to a solution that
Is technically feasible?
Has acceptable costs (development, production, operations and support)?
Has acceptable risks?
Adequately satisfies stakeholder needs?
Feasibility Analysis

68. Requirements Verification
The resulting system meets the stated requirements
Requirements Verification Matrix
Maps verification method(s) for each requirement
Analysis, Inspection, Test, Demonstration

69. Key Product Characteristics vs. Requirements
Key Characteristic is a product attribute
Requirement defines product performance or constraint
Key characteristics may represent
Attributes significant to the customer
Attributes that require specific control during manufacture to assure compliance with a requirement

70. The Benefit of Poor Requirements
The benefit of poorly defined requirements is that the inability of the system to perform as desired comes as a surprise

71. Systems Engineering Process
Functional Analysis/Allocation
Decompose to lower-level functions
Allocate performance and other limiting requirements to all functional levels
Define/refine functional levels
Define/refine functional interfaces (internal/external)
Define/refine/integrate functional architecture
Synthesis
Transform architectures (functional to physical)
Define alternative system concepts, configuration items and system elements
Define/refine physical interfaces (internal/external)
Select preferred product and process solutions
Verification Loop
Design loop
Requirements loop
Requirements Analysis
Analyze missions and environments
Identify functional requirements
Define/refine performance and design constraint requirements
System
Analysis
and Control
(balance)
Control
loop
Process output
Phase dependent
Decision support data
System architecture
Specifications and baselines
Process input
Customer needs/ objectives/ requirements
Missions
Measures of effectiveness (MOEs)
Environments
Constraints
Technology base
Outputs from prior phase
Program decision requirements
Requirements applied through specifications and standards
Trade-off studies
Effectiveness analyses
Risk management
Configuration management
Interface management
Data management
Performance based progress measurement
IMP/IMS
TPM
Technical reviews

72. Functional Analysis
The process of translating system requirements into detailed design criteria
Specifies “what” must be accomplished to achieve desired objectives, but not “how”
Operational Functions lead to Maintenance and Support Functions

73. Functional Flow Block Diagrams
System Requirements
Function F
Function E
Function D
Function C
Function B
Function A
1.0
5.0
2.0
3.0
4.0
6.0
System Top-Level Functions
To Second-Level Functions

74. Functional Flow Block Diagrams
5.1
5.2
5.3
5.5
5.4
Second-Level Functions
From System Top-Level Function
To Third-Level Functions
Function E3

75. Functional Flow Block Diagrams
5.5.1
5.5.4
5.5.2
5.5.3
5.5.5
Third-Level Functions
From Second-Level Functions
Function E3e

76. First Level

77. 2nd Level

78. 3rd Level

79. IDEF Notation (Integrated Definition Methods)
CONTROLS/CONSTRAINTS
INPUTS
MECHANISMS
OUTPUTS

80. 2. Requirements Allocation
Identification of specific resource requirements at the subsystem level and below
Conversion to “hows” is accomplished by evaluating each individual functional block
Includes Hardware, Software, Human!

81. Functional Allocation
Production and/or
Construction
Conceptual Design
Preliminary
Design
Detail Design Development
System Level
Requirements
Analysis
Functional
Allocation
Trade-off
Studies
Synthesis
Evaluation
System Specification
Design Review(s)
0.1
0.3
0.4
0.5
0.6
0.8
0.7
0.2
0.0
Baseline
Allocated
Product
(System Integration and Testing)
The Hardware Life Cycle
The Software Life Cycle
The Human System
Integration Life Cycle
Day-To-Day Interaction
Feedback and Control
2.3
The Evolution of Hardware, Software,and Human Requirements from the Functional Analysis
Feedback
(Adapted From: Blanchard and Fabrycky, “System Engineering and Analysis, Prentice Hall, 1998/2005)

82. Example Feasibility Analysis Need To Develop a Transportation Capacity
Between City A and City B
Feasibility Analysis OR
Ground
Transportation
Airborne
Transportation
Waterway
Transportation
Result of Analysis
(Select Airborne Transportation Capability)
(Adapted From: Blanchard and Fabrycky, “System Engineering and Analysis, Prentice Hall, 1998)

83. Example of QFD-Style Chart
Alternatives G A W
Safety
Convenience
Speed
Availability
Reliability
Cost
Evaluation
Criteria -
Decreasing
Importance Hi
Med
Low

84. To Second-Level Functional Flow
Functional Analysis
System Top-Level
Functional Flow 9 2 5
Operate
The System
In User
Environment
Design
Aircraft
System
Produce
Prime System
Elements 1 8 4 6
Define
System
Requirement
(Oper. Maint.)
Distribute
System for
Consumer Use
Perform
System
Integration
And Test
Procure
Elements of
Support OR
AND
AND 3 OR 7 10
Design
System
Support
Capability
Produce
Elements of
Support
Maintain the
System
(As Required)
What is wrong?
To Second-Level Functional Flow
(Adapted From: Blanchard and Fabrycky, “System Engineering and Analysis, Prentice Hall, 1998/2005)

85. Second-Level Functional Flow Third-Level Functional Flow
9.1
9.3
9.4
9.5
9.6
9.7
Prepare
Aircraft for
Flight
Taxi Aircraft
For Takeoff
Takeoff
From City A
Process
From
City A to
City B
Land at
City B
Perform
Aircraft
Checkout
9.0 OR
Ref
Operate the
System in User
Environment
9.2
Prepare
Aircraft for
Standby
Third-Level Functional Flow
9.5
9.5.1
9.5.2
9.5.3
9.5.4
Ref
Process
From City A
To City B
Check
Communication
Subsystem
Contact
Control Tower
City A
Contact
Control Tower
City B
Receive Landing
Instructions G
Maintenance Flow
(Adapted From: Blanchard and Fabrycky, “System Engineering and Analysis, Prentice Hall, 1998)

86. Maintenance Functional Flows
9.5.1
REF
Check
Communication
Subsystem
Check for
Voice Communication
(High Frequency)
(Low Frequency)
Power
Output
Isolate
Malfunction to
Faulty Assembly
Transport
Faulty Unit to
Intermediate
Maintenance Shop
Remove
Applicable Unit
From System and
Replace With Spare
Fault to
Unit A
Accomplish
Repair of Unit
In Place
And Replace
With Spare
Verification of
Unit Repair
Through Test
Return
Operational Unit
To Spares Inventory
15.1
15.2
15.10
15.8
15.9
15.7
15.6
15.5
15.4
15.3
15.11 G OR
(Adapted From: Blanchard and Fabrycky, “System Engineering and Analysis, Prentice Hall, 1998)

87. Requirements Allocation (Functional Packaging)
System
Requirement
Operational
Activity
Operational
Function
Functional
Packaging
Subfunctions
1.0-Bearing
Information
1.1-Bearing
Alarm
Unit A
And
1.3-Bearing
Validity
2.0-Tone
Information
1.2-Azimuth
Signal
And
3.0-Control
Function
2.1-Tone
Identity
Operational
Mode 1
And
4.0-Self-Test
Function
2.2-Tone
Volume
System
XYZ Or
Operational
Mode 2
Operational
Mode 3
See Figure 4.5
(Adapted From: Blanchard and Fabrycky, “System Engineering and Analysis, Prentice Hall, 1998/2005)

88. System XYZ Operational Mode 1 1.0-Bearing Information 5.1-Range
Signals
And
5.3-Range
Alarm
2.0-Tone
Information
5.2-Range
Validity
System
XYZ Or
And
5.4-Range
Measurements
Unit B
5.0-Range
Information
4.1-Continuous
Self-Test
Operational
Mode 2
And
4.3-Interruptive
Self-Test
3.0-Control
Function
4.2-Go/No-Go
Indicators
Operational
Mode 3
4.0-Self-Test
Function
6.1-Receive
Inter-Pulses
And
5.0-Range
Information
6.2-Transmit
Reply
6.0-Transpond
Ing Function
And
3.1 Power
Transfer
Unit C
3.0-Control
Function
And
3.3-Modes
Operation
3.2 Channel
Selection
4.0-Self-Test
Function
(Adapted From: Blanchard and Fabrycky, “System Engineering and Analysis, Prentice Hall, 1998/2005)

89. Tactical Aircraft Example

90. Built-In Oven Example Select Upper Compartment START Lower End (ServeOR
Select
Upper
Compartment
Lower
Mode
Broil
Convection
Conventional
Temperature
Start
Heating
Preheat
Completed?
Insert
Items
Continue
Cooking
Time
Monitor Cooking
AND
Remove
Turn
Off
End
(Serve
& Eat)

91. 3. Design Requirements Design for: Functional Capability and
Reliability
Maintainability
Usability and Safety (Human Factors)
Supportability and Serviceability
Producibility and Disposability
Affordability (Life-Cycle Cost)

92. Reliability
Reliability is the characteristic of design and installation concerned with the successful operation of the system throughout its planned mission.
(More in Chapter 12)

93. Maintainability
Maintainability is the characteristic of design and installation that reflects the ease, accuracy, safety, and economy of performing maintenance activities.
(More in Chapter 13)

94. Usability and Safety
Usability (Human Factors) is the characteristic of design concerned with the interfaces between the human and hardware, the human and software, etc., i.e., ensuring compatibility and safety.
(More in Chapter 14)

95. Supportability and Serviceability
Supportability and Serviceability are the characteristics of design that ensure that the system can ultimately be serviced and supported effectively and efficiently throughout its planned lifecycle. (Focus on Logistics)
(More in Chapter 15)

96. Producibility and Disposability
Producibility/Disposability is that characteristic of design that pertains to the ease and economy of producing/disposing of a system or product, without sacrificing function, performance, effectiveness or quality.
(More in Chapter 16)

97. Affordability
Economic feasibility or affordability are characteristics of design and installation that impact budget constraints.
(More in Chapter 17)

98. 4. Engineering Design Technologies
Computer-Aided Engineering Design
Analytical Models and Tools
Simulation

99. Computer-Aided Engineering Design
Computer Aided Analysis
CAD – Computer Aided Design
CAM – Computer Aided Manufacturing

100. Analytical Models and Tools
(Chapters 7 – 11)
Economic Models
Optimization (Prescriptive) Models
Descriptive Models (Simulation?)
Control Systems

101. Synthesis and Design Definition
Synthesis – the combining and structuring of components in such a way as to represent a feasible system configuration.
(Allocated) baseline configuration is developed in order to move into detail design and development!

102. Synthesis and Design Definition
System synthesis is achieved when sufficient preliminary design progress has been made and tradeoff studies have been accomplished to confirm and assure the completeness of system performance and other design requirements.

103. Synthesis and Design Definition
The performance, configuration and arrangement of a chosen system and its elements are portrayed along with the techniques for their test, operation, and lifecycle support.

104. Missouri University of Science & Technology
Program Completed
Missouri University of Science & Technology
© 2003 Curators of University of Missouri