1. Principles of Systems Engineering Introduction & Overview
Jim Andary
NASA Goddard Space Flight Center
October 22, 2009

2. Agenda Definitions of system and systems engineer
The role of a systems engineer
Systems engineering vs. project management
Systems engineering functions and processes
Requirements Development and Management
Operations Concept
Decomposition
Technology Planning
System analysis and design
System Integration
Resource Management
Quality Control
Verification and Validation

3. Definitions What is a System?
“A System is a set of interrelated components which interact with one another in an organized fashion toward a common purpose”
NASA Systems Engineering Handbook SP6105

4. Definitions (Continued)
What is Systems Engineering?
“Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems.”
INCOSE Handbook

5. Definitions (Continued)
Another Definition
“Systems Engineering is a robust approach to the design, creation, and operations of systems.”
NASA Systems Engineering Handbook SP-6105

6. Definitions (Continued)
In simple terms, the systems engineering approach consists of:
Identification and quantification of system goals,
Creation of alternative system design concepts,
Performance of design trades,
Selection and implementation of the best design,
Verification that the design is properly built and integrated, and
Post implementation assessment of how well the system meets (or met) the goals

7. Definitions (Continued)
“Engineering of Systems”
Anyone involved in engineering a system should exercise good systems engineering practices.

8. Twelve Systems Engineering Roles
1. Requirements Owner
2. System Designer
3. System Analyst
4. Validation and Verification Engineer
5. Logistics & Operations Engineer
6. Owner of the “Glue” among subsystems
7. Customer Interface
8. Technical Manager
9. Information Manager
10. Process Engineer
11. Coordinator of the Disciplines
12. “Classified Ads” Systems Engineer
To solve a complex problem, we must deal with the problem in a way that fits with how we think.
Engineering at any level involves some of this type of thinking—we always break the problem up into more manageable chunks.
Systems engineering typically refers to problems which are so complex that different people must work on the different pieces of the problem.
Specialists handle the details and systems engineers make sure the pieces work together to form something which is more than the sum of its parts.
INCOSE--
System designer decides how to break up system. Requirements owner manages requirements which define system and subsystems. System analyst confirms that the designed system will meet requirements. Val/Ver Engineer makes sure the system does meet requirements. Ops Engineer maintains system through operations and end-of-life. Glue role makes sure things don’t fall through the cracks. CI, TM, IM, PE are fairly obvious. Coordinator facilitates group actions. Last one refers to engineers involved with information technology—formerly maintainers of mainframe computer system.
1. Requirements Owner
Requirements manager, allocator, and maintainer
Specifications writer or owner
Developer of functional architecture
Developer of system and subsystem requirements from customer needs
System Designer
Owner of "system" product
Chief engineer
System architect
Developer of design architecture
Specialty engineer (some, such as human-computer interface designers)
“Keepers of the holy vision" [Boehm 94]
3. System Analyst
Performance modeler
Keeper of technical budgets
System modeler and simulator
Risk modeler
Specialty engineer (such as electromagnetic compatibility analysts)
4. Validation and Verification Engineer
Test engineer
Test planner
Owner of the system test program
System selloff engineer
5. Logistics and Operations Engineer
Logistics
Operations
Maintenance and disposal engineer
Developer of users’ manuals and operator training materials
6. Owner of the "Glue" among subsystems
System integrator
Owner of internal interfaces
Seeker of issues that fall "in the cracks"
Risk identifier
“Technical conscience of the program" [Fisher 92]
7. Customer Interface
Customer advocate
Customer surrogate
Customer contact
8. Technical Manager
Planner, scheduler, and tracker of technical tasks
Owner of risk management plan
Product manager
Product engineer
9. Information Manager
Configuration management
Data management
Metrics
10. Process Engineer
Business process reengineer
Business analyst
Owner of the systems engineering process
11. Coordinator of the disciplines
Tiger team head
Head of integrated product teams (IPTs)
System issue resolver
12. “Classified Ads” Systems Engineering
What ever special engineering is necessary to keep things from falling through the cracks.
from Sarah A.Sheard (INCOSE proceedings of 1996)

9. Systems Engineering vs. Project Management

10. Key Systems Engineering Functions
Verification and Validation
Project Objectives and Constraints
Requirements Development and Management
Architecture and Design
Tools help engineers evaluate their systems more quickly and more efficiently, but they do not replace the “Art” and “Creativity” necessary to conceive them
Verification
and
Validation
Verification and Validation
Project Objectives Met,
Ready for Operations
Operations Concept
Systems Engineering Management Plan
“The objective of systems engineering is to see to it that the system is designed, built, and operated so that it accomplishes its purpose in the most cost-effective way possible, considering performance, cost, schedule and risk.”
NASA Systems Engineering Handbook SP6105

11. Systems Engineering Process “V”
Understand User
Requirements, Develop
System Concept and
Validation Plan
Demonstrate and
Validate System to
User Validation Plan
Develop System
Performance Specification
and System
Verification Plan
Integrate System and
Perform System
Verification to
Performance Specification
Expand Performance
Specifications Into CI
“Design-to” Specifications
and Inspection Plan
Assemble CIs and Perform
CI Verification to CI
“Design-to”
Specifications
Evolve “Design-to”
Specifications into
“Build-to” Documentation
and Inspection Plan
Inspect to
“Build-to”
Documentation
Verification Sequence
Integration and
Decomposition &
Definition Sequence
Fabricate, Assemble, and
Code to “Build-to”
Documentation
CI = Configuration Item

12. Systems Engineering Process “V” (Continued)
Developed by Kevin Forsberg and Harold Mooz*
Starts with user needs on the upper left and ends with a user-validated system on the upper right
Adds concurrent risk management
User involvement
User approval and in-process validation
Adds verification problem resolution
Promotes a risk-responsive, phased system development process
*Kevin Forsberg and Harold Mooz, "The Relationship of System Engineering to the Project Cycle," Proceedings of the First Annual Symposium of National Council on System Engineering (NCOSE), Chattanooga, Tennessee, Oct. 1991, pp

13. Requirements Development
Collect top-level requirements from customers and stakeholders
Develop an operations concept
Derive lower-level requirements to support top-level requirements and the operations concept
Writing requirements without a fully understood, agreed upon and documented operations concept will result in poor and misunderstood requirements, cost overruns and schedule slips.

14. Requirements Development (Continued)
Writing Good Requirements
“Functional Requirements” - What needs to be done
Functional Requirements are generally not Verified because Performance Requirements specify how good the function needs to be
Functional Requirements define a logical breakdown
“Performance Requirements” - How well it needs to be done
Performance Requirements are Verifiable
Requirements Decomposition and Parent-Child Relationship
Requirements flow from higher to lower levels
Requirements at lower levels (“children”) must trace from a higher level requirement (“parent”)
Eliminate any “orphan requirements” (requirements without parents)
Add rationale or comments to the requirements to help trace “why” that requirement was created

15. Requirements Development (Continued)
Decompose the requirements in a hierarchical, parent-child relationship
Requirements flow from higher to lower levels
Requirements at lower levels (“children”) must trace from a higher level requirement (“parent”)
Eliminate any “orphan requirements” (requirements without parents)
Add rationale or comments to the requirements to help trace why that requirement was created

16. Requirements Development (Continued)
Writing the right requirements
What is necessary to Achieve Full Mission Success Criteria?
Levels of requirements (Level 1, Level 2, etc.)
Level 1 Generally Highest Level Agreement with Ultimate Customer
Lower Levels up to each Project to choose
Traceability (Parent, child, orphan, widow, etc.)
Priorities
Organizing the requirements
(templates and guidelines)
Reviewing Requirements
Gate keepers
Formal reviews (SRR, PDR, CDR)
Verification Plan must addresses
how each requirement will be verified

17. Requirements Development (Continued)
Use the word “shall” when defining requirements and only for requirements:
“The attitude control system shall point the instrument boresight to within 6 arc seconds of the commanded attitude.”
Make it clear to the reader exactly what must be done.
Requirements should be:
Measurable
Avoid vague statements like “shall point as accurately as possible”
Verifiable
If no one can demonstrate that a system does or does not meet a requirement, then there is no requirement: shall not exceed 55 kg, but we aren’t going to weigh it
Document rationale!
Capture the “why” while it is fresh.
Enable future changes—people are afraid to change things they don’t understand.

18. Requirements Development (Continued)
What the Proposal Promised
Preliminary Design
Design Drawings
The Customer’s Swing
The customer requested a new kind of swing that allowed the customer more than one way of swinging.
As Built by Manufacturing
Following Inspection and Rework
What the Customer Wanted
Design Change Specification
After Rework
What Happened to
The Engineering Team
Communication and Understanding is Key!

19. Requirements Management
Collect top-level requirements from customers and stakeholders
Develop operations concept
Derive lower-level requirements to support top-level requirements and the operations concept
Choose an appropriate tool to store and manage the requirements
This can range from an Excel spreadsheet for simple projects to sophisticated tools such as DOORS, Team Center, CORE, etc. for more complex projects
Baseline the requirements at a System Requirements Review (SRR)
“Baseline” means requirements are signed off and put under configuration control
Control any future changes to requirements through a configuration management process

20. Requirements Management (Continued)

21. Operations Concept
An Operations Concept is a vision (in general terms) for what the system is, and a description of how the system will be used.
An Operations Concept consists of a set of scenarios describing how the system will be used during all of its operational phases.
The scenarios are often accompanied by illustrations of the system operations.
An Operations Concept:
Serves as a validation reference for the design throughout the life cycle
Describes how the design can accomplish the mission described by the objectives
Key to defining all the requirements
Evolves into the flight operations plan later in the life cycle

22. Operations Concept (Continued)
Stakeholders participate in the development of the Operations Concept
Trade studies and analyses are used to demonstrate that the operations concept will meet the mission requirements within cost and schedule constraints

23. Operations Concept (Continued)
Considerations for developing an Operations Concept for a Space Mission:
Allocation of functions between ground segment and flight segment
Mission operational modes and configurations
Time ordered sequence of mission activities
Identification of facilities, equipment and procedures needed to ensure the safe development and operation of the system
Operations team size, staffing and extent of automation
Ground segment functions
Contingency concepts
Ground test configurations necessary to accomplish verification including GSE, BTE, simulators and non-flight articles such as ETU’s
Description of functions that cut across various subsystems
Observation strategy
Date collection, storage and downlink
Ground station utilization
Mission orbit maintenance and maneuvers
Power and battery management

24. Operations Concept (Continued)
Military Planners
Satellite Operators
Control Center
Request
for Data
Data
Inter -Satellite Link
Data Download
Command Transmission
Image Recording

25. Many types of decomposition
Requirements Decomposition
Functional Decomposition
Functional Architecture
Physical Decomposition
Physical Architecture
Operational Architecture
Allocates functions to physical subsystems
Provides complete description of the system design
Integrates the requirements decomposition with the functional and physical architectures

26. Decomposition (Continued)
System Requirement
User Defined
non-exhaustive
inclusive
based on content and allocation
Effectiveness
Measure
Functional
Requirement
Performance
Requirement
Physical
Property
Requirement
Interface
Requirement
Imposed Design
Requirement
Reference
Requirement

27. Technology Planning
Projects are sometimes initiated with known technology shortfalls
Technology “Pull”
Often there are areas for which new technology will result in substantial product improvement
Technology “Push”
Technology development can be done in parallel with the project evolution and inserted as late as the PDR
Risk mitigation requires a parallel approach that is not dependent on the development of new technology
The technology development activity should be managed as a critical activity

28. Technology Readiness Levels

29. Systems Analysis and Design
Modeling
Models are the language of the designer.
Models are representations of the system-to-be- built or as-built.
Models are a vehicle for communications with various stakeholders.
Models allow reasoning about characteristics of the real system.
Models can be used for verification by analysis.
All models must themselves be verified.

30. Systems Analysis and Design (Continued)
There are two basic approaches that are commonly used for system design and integration
Structured Analysis
Object-oriented Analysis and Design
It can be shown that either approach can be translated into the other.

31. Structured Analysis Structured Analysis
Process Modeling, also known as Data Flow Modeling or Functional Decomposition
IDEF0*
SADT (Structured Analysis & Design Technique)
Data Modeling
IDEF1x
Entity-Relationship Diagrams
Behavior Modeling
Rules
State Transition Diagrams
*The IDEF process was developed by the Air Force in the early 1970’s as part of the ICAM program (Integrated Computer Aided Modeling). IDEF originally stood for “ICAM Definition” but NIST later changed it to “Integration Definition”.

32. Structured Analysis (Continued)
IDEF0
Student
Registration
System

33. Structured Analysis (Continued)
“ICOM”
Control
Input
Function
Output
Mechanism

34. Structured Analysis (Continued)
Behavior Modeling: State Transition Diagram
Ready
User ID and Password entered
(User_ID, Password)/ accept
Verifying
start
Do: display login page
Do: wait for login
Do: verify user
[Invalid user]/Display:”Access Denied”
[Valid user]
Validating Options
Retrieving
[Option selected
not allowed]/
Display error message:
“Option not allowed”
Request for course search
Do: display user options
Do: check option vs access permission
Do: display course search page
Do: retrieve course selections
[Registration rejected]
Request to register (course_nr, user_ID)
Request to generate report (User type)
Request to register
(course_nr, user_ID)
Registering
Validating Report
[Report not allowed]/
Display error message
“Option not allowed”
Do: display report page
Do: validate user vs report selected
See superstate diagram
[No Conflicts] (course_nr)
Report printed
(Report type) [Report allowed]
Drop request (course_nr)
Updating Schedule
Generating Report
Do: update student schedule
Updating complete/
University-updated
class roster
Do: send database request (report parameters)
Do: format report
Do: print (report)

35. Structured Analysis (Continued)
IDEF1x
DATA MODEL

36. Object-Oriented Analysis and Design
The concept of “object” or “object class” is the result of a long history of software engineering design.
From a programming viewpoint, an object is a collection of specialized data packaged with the functions (operations and methods) which are needed specifically by that specialized data.
From a systems design viewpoint, an object is a system or component which maintains its own information and is able to perform some specific functions.
Developed more recently for software engineering, object- oriented design is now migrating to systems engineering.
Object-oriented design defines the relationships between object classes and the behavior of the classes.

37. Unified Modeling Language (UML)
UML is a language for visualizing, specifying, constructing and documenting the artifacts of software-intensive systems, as well as for business modeling and other non-software systems.
UML supports the entire development lifecycle.
UML is supported by many tools (e.g., IBM Rational ROSE, Visio, etc.).
SysML is the extension of UML to systems engineering.

38. Domain of Interest System View Realization View System Requirement
(3)
contained in
Domain
of Interest
contained in
Category
(2)
built from
reference for C
categorizes
(63)
(5)
System
View
Functional
Breakdown
(64)
(7)
(6)
System
Breakdown
has view
Stakeholder
Environment
Element
exhibits
part of
Physical
Breakdown C
(1)
(65)
has
(62)
(61)
(8)
(4)
Interacts with
Design View
Realization
View
Stakeholder
Need
satisfied by
System
(9)
(11)
allocated to
System
Requirement C
Reference
Document
Property
represented by
statement of
reference for
(10)
derived from
verifies
(12)
(14)
(13)
Physical
Property
Structure
Verification
Behavior C C
allocated to
budgeted to

39. Unified Modeling Language (UML)
(3)
Domain
of Interest
Box means Class or Meta Class (top is name) or type
2nd box means attributes
3rd box means Methods or member functions
Diamond means aggregation/decomposition
Line means relationship (words on line describe relationship)
(XX) Means look at Concept semantic dictionary
Diamond with a C in the middle means a Complete decomposition
Loop line with Diamond means hierarchal decomposition of items of the same type
Arrow/triangle means specialization/generalization Depending on direction
A number on each end of a line means multiplicity
(1) C
(4)
(22.10) 1 1
From MDSD Workshop 5 Feb 2003

40. UML vs. SysML

41. Integrated Mission Design Center (IMDC) at Goddard Space Flight Center
“Concurrent Design”
Integrated Mission Design Center (IMDC)
at Goddard Space Flight Center

42. Preliminary design in one week vs. six months
“Concurrent Design”
Collaborative, Rapid Design Improves Quality of Conceptual Designs
Preliminary design in one week vs. six months

43. Small Explorers (SMEX) Built at GSFC
Submillimeter Astronomy
Satellite (SWAS)
Transition Region And
Coronal Explorer (TRACE)
Wide-Field Infrared
Explorer (WIRE)
Note cut-outs in blankets for heat rejection.
Cryostat is not blanketed—runs cold.
Note star tracker and shade.
Note RF comm antenna.
Note safety vent.
Solar
Anomalous
and
Magnetospheric
Particle
Explorer
(SAMPEX)
Fast
Auroral
Snapshot
Explorer
(FAST)

44. System Integration
Integration is the process of assembling the system from components.
Integration begins with the elementary pieces or configuration items (CI’s) of the system.
After each CI is tested, components comprising multiple CI’s are tested.
This process continues until the entire system is assembled and tested.
Interface Specifications and Interface Control are critical to a successful system integration.

45. Work and Resource Management
A Work Breakdown Structure (WBS) is a hierarchical breakdown of the work necessary to complete a project.
The WBS should be a product-based, hierarchical division of deliverable items and associated services.
The WBS should contain the Product Breakdown Structure (PBS).
At the lowest level are products such as hardware items, software items, and information items (documents, databases, etc.) for which there is a cognizant engineer or manager.
A project WBS should be carried down to the cost account level appropriate to the risks to be managed.

46. Work Breakdown Structure (WBS)

47. Product Breakdown Structure (PBS)

48. Technical Resource Management
Critical mission resources shall be identified, allocated and managed
Acceptable resource margins shall be established
A margin management philosophy shall be set up based on design maturity and time
Required margins are reduced as the project matures
Margins are assessed based on the fidelity of the estimate
Care must be taken that margins are not added to margins
Stacked margins that do occur simultaneously in real life
Lead systems engineer holds the overall system margins
Subsystem engineers must be allowed to hold some margin in order to meet their design requirements
This hierarchy of margins must be taken into account so that the overall system margins do not drive the design and the cost
Margin costs money, so there is always pressure to reduce margin.
Use good judgment and the experience of others to judge how much margin is appropriate.

49. Example: Technical Resource Margins
Tracking Estimates (Mass)
Allocations defined at SRR for appropriate total margin
Estimates tracked monthly
Changes to allocation via CCR
Estimates over total allocation trigger risk reduction activities

50. Specialty Engineering
Specialty engineers support the systems engineering process by applying specific knowledge and analytic methods from a variety of engineering specialty disciplines to ensure that the resulting system is actually able to perform its mission in its operational environment.
For space systems these specialty areas often include:
Quality Assurance
Reliability
Maintainability
Producibility
Logistics
Safety
Environment (e.g., radiation, atomic oxygen, atmospheric density, etc.)
Contamination
Parts Engineering

51. Reliability * Performance
Quality Assurance
Performance
Providing confidence that the system
actually produced and delivered is in
accordance with its functional,
performance, and design requirements.
Quality
Cost
Time
Engineering
Efficiency =
Reliability * Performance
Cost * Time

52. The “Bathtub Curve” Reliability
For many systems, the failure rate function looks like the classic "bathtub curve" illustrated in the graph below.
Failures
Random Failures
Burn-in Period
Useful Life Period
Wear-out Period
Time

53. Maintainability
Maintainability is that system design characteristic associated with the ease and rapidity with which the system can be retained in operational status, or safely and economically restored to operational status following a failure.

54. Verification Verification: “Did I build the System Right?”
Each requirement must be verified
Verification Methods: Test, Analysis, Inspection and Demonstration
Rule #1: “Test wherever possible”
Perform Analysis and Inspection, where Test is not possible
Pay careful attention to validity of simulators and models
Rule #2: “Test the way you fly, fly the way you test”
Identify what is not tested in flight configuration
Careful review to assure items are properly verified by a combination of Analysis, Inspection or Test.
Review of the assumptions and interfaces of element verified in pieces
Attention to validity of simulators and simulations
Careful review to assure these items are properly verified by a combination of Analysis, Inspection or Test.

55. Verification (Continued)
Rule #3: “Test the system end-to-end”
Carefully review the assumptions and interfaces of any elements verified in pieces
Rule #4: “Verify Off-Nominal Conditions”
Verify Redundancy and Graceful Degradation Modes along with On Board Fault Protection and Ground Contingency Procedures
Stress Testing and Negative Testing to find Latent Flaws

56. Validation Validation: “Did I design or build the Right System?”
Validation shows that the Design when used according to the Operations Concept meets the Requirements and the Customers Goals and Objectives and can be produced within the Cost, Schedule and Risk constraints
Validation Methods: Analysis, Predictions, Trade Studies, Test
The requirements flow is also validated to show that “Parent” requirements have valid “Child” requirements and that “Orphan” requirements are not driving the system design or implementation.
Initial Validation during Phase A and B is critical to proceeding into Phase C where detail design occurs
Otherwise the detail design proceeds on the “Wrong” system
Validation also occurs in parallel with verification where End to End Tests, Mission Simulations show that the “Right System” has been built

57. Summary Systems Engineering addresses the total program lifecycle
Largely a communications activity
Consistent Requirements, Design, and Operations Concept
Time Phased “Crawl Before You Walk, Walk Before You Run”
No Cookbooks or Magic Recipes
Multilayered Review, Inspection and Test Process
It is the Project Team, the People, that makes projects successful
Systems Engineering Techniques Balance Performance, Cost, and Schedule

58. Some Key References
Andrew P. Sage and William B. Rouse, Handbook of Systems Engineering and Management, 2nd edition, John Wiley, 2009
ISO/IEC 15288, Systems engineering — System life cycle processes, 2002
Dennis M. Buede, The Engineering Design of Systems: Models and Methods, Wiley, 2000
ANSI/EIA , Processes for Engineering a System, Electronic Industries Alliance, 1999
IEEE 1220, Management of the Systems Engineering Process
INCOSE-TP , INCOSE Systems Engineering Handbook v3.1, 2007
SP , NASA Systems Engineering Handbook

59. Homework Assignment
In a brief paragraph describe a system of your choosing
In another paragraph describe its operation (operations concept)
Draw a high-level product breakdown structure (PBS) for that system