EBOOK

A Guide to Good Systems Engineering

Practices: The Basics and Beyond
 Table of Contents
Part I: The Basics of Systems Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
What is systems engineering? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
What are the fundamentals of systems engineering? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
What is a system? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
What is systems thinking? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
What is the role of a systems engineer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
How can systems engineers help improve traceability?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
What is the systems engineering Process?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
The “V” diagram of systems engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Part II: Systems Engineering Beyond the Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Systems of systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
The 10 characteristics of good systems engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Lessons learned in systems engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Resources to manage increased complexity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 2
1 Part I: The Basics of Systems Engineering
PART 1 | The Basics of Systems Engineering

What is systems engineering?

Systems engineering is an engineering field that
takes an interdisciplinary approach to product
development. Systems engineers analyze the
collection of pieces to make sure when working
together, they achieve the intended objectives
or purpose of the product. For example, in
automotive development, a propulsion system
or braking system will involve mechanical In the first part of this eBook, we discuss:
engineers, electrical engineers, and a host of  The fundamentals of systems engineering
other specialized engineering disciplines. A  The role of a systems engineer
systems engineer will focus on making each of the
 Systems engineering process
individual systems work together into an integrated
 The “V” Model of systems engineering
whole that performs as expected across the
lifecycle of the product.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 4
PART 1 | The Basics of Systems Engineering

What are the

fundamentals of
systems engineering? Development
Phasing

In product development, systems engineering is the

interdisciplinary field that focuses on designing, LIFECYCLE
BASELINES
PLANNING
integrating, and managing the systems that work
Systems
together to form a more complex system. Systems Engineering
engineering is based around systems-thinking Management
principles, and the goal of a systems engineer is to
Systems Lifecycle
help a product team produce an engineered system Engineering Integration
that performs a useful function as defined by the Process
INTEGRATED
requirements written at the beginning of the project. TEAMING

The final product should be one where the individual

systems work together in a cohesive whole that meets
the requirements of the product.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 5
PART 1 | The Basics of Systems Engineering

What is a system?
A system is a collection of different elements that produce
results that individual elements cannot produce. Elements or
parts can be wide-ranging and include people, hardware,
software, facilities, policies, and documents. These elements
interact with each other according to a set of rules that produce
a unified whole with a purpose expressed by its functioning. An
example of a system is the human auditory system; the system
includes individual parts in the form of bones and tissue that
interact in a way to produce sound waves, which are
transferred to nerves that lead to the brain, which interprets the
sounds and formulates a response. If any single part in the
auditory system fails or experiences disruption, the entire
system can fail to perform its function.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 6
PART 1 | The Basics of Systems Engineering

What is systems thinking?

Systems thinking is a way of thinking that looks at the overall
function of a complex system rather than breaking it down into
smaller parts. For example, systems thinking would consider an
automobile a complex system that consists of smaller, specialized
elements. While an electrical engineer might only be concerned
with the electrical system of the automobile, someone looking at
the entire complex system would consider how the electrical
system would impact other systems in the automobile — and how
those other systems might impact the electrical system. If one
piece of the electrical system fails, for instance, how would that
failure cascade to other systems to impact the operability of the
automobile? Systems thinking will take a “big picture” approach to
the overall product.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 7
PART 1 | The Basics of Systems Engineering

What is the role of a

systems engineer?
A systems engineer is tasked with looking at the entire integrated system and
evaluating it against its desired outcomes. In that role, the systems engineer
must know a little bit about everything and have an ability to see the “big
picture.” While specialists can focus on their specific disciplines, the systems Learn more about the
engineer must evaluate the complex system — as a whole — against the initial Systems Engineering
requirements and desired outcomes. Body of Knowledge
Systems engineers have multi-faceted roles to play, but primarily assist with: (SEBoK), a living,
breathing document
 Design compatibility
that was designed to
 Definition of requirements
help systems engineers
 Management of projects
work better.
 Cost analysis
Download The Complete Guide to
 Scheduling
the Systems Engineering Body of
 Possible maintenance needs Knowledge (SEBoK) »
 Ease of operations
 Future systems upgrades
 Communication among engineers, managers, suppliers,
and customers in regard to the system’s operations

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 8
PART 1 | The Basics of Systems Engineering

How can systems engineers

help improve traceability?
For many systems engineers, balancing the needs of the individual systems
and their engineers against the system as a whole results in addressing
problems after the fact, holding unwanted meetings, and trying to
persuade others to change behavior. Many organizations may not
adequately focus on requirements and traceability, resulting in a lack of
data that would allow a systems engineer to better evaluate the product.
To avoid constantly chasing problems and start streamlining
processes, systems engineers can use three best practices:

 Baseline the current traceability performance: Traceability spans

the product development process, and product team members
understand the value of data management, especially as concerns
meeting industry requirements. By establishing a baseline of
traceability performance, the entire team will be able to see existing
risks and potential savings and improvements. In addition, a baseline can
give a foundation for a plan of action to move toward Live Traceability™.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 9
PART 1 | The Basics of Systems Engineering

 Build the business case for Live Traceability: With a

baseline in hand, systems engineers can offer a case for
moving to Live Traceability based on data. The data can
establish the ROI, productivity improvements, and risk
reduction of moving from static traceability to Live
Traceability.
 Create quick wins: Once the advantages of Live
Download this whitepaper
Traceability are established, the systems engineer can set to learn five tips that will
up continuous syncing between requirements and task help you produce the
management programs, thus automating traceability from kind of traceability that
requirements to user stories. This simple shift can help allows teams to more
demonstrate the value of shifting from after-the-fact effectively and efficiently
traceability to Live Traceability. manage complexities
across the entire product
development process.
Download our whitepaper, Better
Product Development: Five Tips to
Achieve Live Traceability »

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 10
PART 1 | The Basics of Systems Engineering

What is the systems

engineering process?
The systems engineering process can take a top-down approach, bottoms up, or
middle out depending on the system being developed. The process encompasses all
creative, manual, and technical activities necessary to define the ultimate outcomes
and see that the development process results in a product that meets objectives.

The process typically has four basic steps:

1. Task definition/analysis/conceptual: In this step, the systems engineer works with stakeholders to understand
their needs and constraints. This stage could be considered a creative or idea stage where brainstorming takes
place and market analysis and end user desires are included.
2. Design/requirements: In this phase, individual engineers and team members analyze the needs in step one and
translate them into requirements that describe how the system needs to work. The systems engineer evaluates the
systems as a whole and offers feedback to improve integration and overall design.
3. Create traceability: Although we’re listing traceability here as the third step, traceability is actually created
throughout the lifecycle of development and is not an isolated activity taking place during one phase. Throughout
the lifecycle of development, the team works together to design individual systems that will integrate into one
cohesive whole. The systems engineer helps manage traceability and integration of the individual systems.
4. Implementation/market launch: When everyone has executed their roles properly, the final product is
manufactured or launched with the assurance that it will operate as expected in a complex system throughout its
anticipated lifecycle.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 11
PART 1 | The Basics of Systems Engineering

 Parametrics
Value Evaluation/  Trade Studies
CRITERIA
System Optimization  Risk Analysis

OBJECTIVES

Mission Functions & Alternative

Analysis Requirements Generation & Verification
 Mission Analysis & Architecture
Mission  Test Lifecycle
Statement Allocation Selection  Inspection
Need  Initial & Final Performance System
Operations
   Demonstration
States  Constraints Description  Analysis
 Interface  Decision
Analysis

Source credit: The Generic TWRS Systems Engineering Process. From Westinghouse Hanford Company, National Academies of Sciences, Engineering, and Medicine. 1998.

Requirements are the foundation of a smooth-running process and are the

essential inputs to your mission-critical projects. Learn more about writing
requirements using the EARS syntax.
Download Adopting the EARS Notation to Improve Requirements Engineering »

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 12
PART 1 | The Basics of Systems Engineering

The “V” diagram of

systems engineering
Developed in the 1980s, the “V” Diagram of Systems Engineering is a
way of specifying the specific series of steps that make up a systems
engineering approach. While it was originally employed in a pre-Agile
environment, it still has relevance to product development today and can Why is Live
enable faster, less risky product development.
Traceability Essential?
The “V” diagram allows system engineers multiple viewpoints and Given the complexity of products
opportunities to evaluate systems as they integrate with each other. This today, it takes multiple team
approach starts with the desired outcomes and objectives and then members to weigh in on key
deconstructs them into individual systems and system components for decisions. And the number of
decision points are only growing
the purpose of design. Once the requirements and design details are
as products get more complex,
established, individual systems can be tested and evaluated, then making it even harder to adequately
integrated into the overall piece for testing and verification. As the weigh all the options and trace their
systems are integrated and become closer to the final complex system, impacts.
teams have multiple opportunities to validate and verify concepts, Learn more »
requirements, and design.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 13
PART 1 | The Basics of Systems Engineering

For the systems engineer, the “V” Model

Verification
can give a clear roadmap that allows the & Validation
CONCEPT OF OPERATION &
breakdown of the complex system into OPERATIONS MAINTENANCE
smaller parts and then the reintegration and
reassembly of the pieces into a cohesive
whole. With systems broken down to
individual components, traceability, Verification
& Validation SYSTEM
requirements management, and testing and REQUIREMENTS
VERIFICATION
& ARCHITECTURE
validation become more manageable. In & VALIDATION

addition, as the pieces are reintegrated into

the whole system, the “V” Model allows for
an iterative process that gives a clearer

tion
Verification

gra
view into potential risks and helps

Pro
& Validation

Inte
DETAILED INTEGRATION, TEST,

jec
troubleshoot problems. DESIGN & VALIDATION

tD

st &
efin

t Te
Systems engineering is a discipline that’s
itio

jec
n

Pro
vital to the success of a complex system. By
including systems engineers in all stages of
product development and requirements
IMPLEMENTATION
management, teams can reduce risks,
improve time to market, and produce better
products that more adequately meet end
user requirements. Time

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 14
 Part II: Systems Engineering
2 Beyond the Basics
PART 2 | Systems Engineering Beyond the Basics

Systems of systems
The discipline of systems engineering can be used on any size engineering effort
and can even be useful when developing products that will be manufactured and
sold to the market. Let’s not confuse what product development is with what systems
engineering is. Designing a System of Systems (SoS) provides good insight into
systems engineering vs. product development.

An example of a SoS is a rail network. Rail cars are designed by one organization, the tracks are installed by another,
the train station is owned and operated by its own group, the rail management software is designed by yet another,
and the customer-facing ticket purchase system is designed and run by yet another organization. Some of these
systems might already be developed and operational. Some might be in the process of an upgrade. Getting the
individual capabilities to work together in an integrated manner is what systems of systems engineering is all about.
Systems engineering for SoS requires planning activities; collaboration and data sharing; analyzing and organizing
the engineering data; and requires special attention to interfaces in order to successfully produce a capability larger
than the sum of its parts.

Needs, requirements, and architectures become the backbone of a SoS effort. Systems engineers will be
coordinating how needs from multiple parties are decomposed into SoS requirements and then coordinating
requirements, architecture, and V&V exchange across the separate organizations that are contributing. For a single
system, agreeing on needs and requirements is straightforward since all involved have the same goal. With SoS,
there might be competing needs and requirements across the organizations and subsystems and in some cases the
needs of one might not be consistent with the needs of another. This is where systems of systems engineering will

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 16
PART 2 | Systems Engineering Beyond the Basics

ENVIRONMENT

need to consider tradeoffs and will RAIL SYSTEM

conduct system analysis.

Maintenance
Passengers Station Rail Cars
& Storage
Systems engineers will perform system
engineering and analysis to determine
how the systems interact with each other Command
from not only a physical standpoint but a & Control

logical, behavioral, functional, cost,

operational viewpoint, and more. System Ticketing Track
analysis is used to perform trade-off System Infrastructure

studies, and includes modeling and

simulation, cost analysis, technical risks
Rail Power
Power Grid
analysis, and effectiveness analysis. System

Learn more about key factors associated with systems engineering

success by reading our whitepaper, The Comprehensive Guide to
Successfully Adopting Model-Based Systems Engineering (MBSE).
Download the guide »

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 17
PART 2 | Systems Engineering Beyond the Basics

The 10 characteristics of good systems engineering

1. The SE team exhibits leadership and ownership. Systems engineers should 6. The SE team has defined the behaviors of the system and understand how
cooperate with all engineering domains as well as project leaders and it relates to the requirements. Mature systems engineering not only defines
ensure that all stakeholders are aware of how the system operates. SE requirements and their verifications and validations but also will flesh out
processes and tools should be enablers for effective decision-making. A behavior of the system and take an iterative approach to requirement creation
defined role exists for chief systems engineer and has equivalent authority in relation to these behaviors. Well-understood system behavior facilitates
to software and hardware managers. understanding of exchanges within the system and with external entities.

2. The SE team has effective communication. Systems engineering has a 7. The SE team keeps relationships between needs, requirements,
regular cadence of communication with stakeholders. Feedback and architectures, risks, and V&V up to date. Systems engineers need to be able
recommendations from systems engineers is founded on data and is to provide valid and up-to-date information to all stakeholders. Creating
maintained in dedicated tools available to all stakeholders. traceability after the fact is a poor practice and incurs risk.

3. The SE team tracks and communicates how the system being developed 8. The SE team demonstrates understanding of the system from concept
is operated. Systems engineering data should be made available in formats through disposal. Systems engineering activities should ideally take place in
that require no additional training and can be consumed by any the earliest stages possible to avoid misunderstandings. Validating the needs
stakeholder. Information should be presented that summarize and provide of the system and problem being solved will ensure alignment between the
automated and real-time status and progress measurements. Web-based customer and the developer. A good systems engineer will consider how the
dashboards with metrics allow for self-service information gathering. system will be used later in its lifetime and even when and how it is to be
decommissioned. Considerations such as these will assist in avoiding
4. The SE team has a defined system boundary and communicates this unforeseen costs.
definition. The systems engineer will properly identify a system’s boundary
by identifying what is being developed and what is not being developed. 9. The SE team manages all types of risks and connects them to mitigations.
They should be able to create a common understanding of the external Systems engineering is not always about what the developed systems should
things that are not part of the system but can either affect the system or be do but also about understanding and communicating what the system should
affected by it. not do. Technical, safety, security, programmatic, and financial risks should be
identified, and mitigation strategies tracked for each by using risk analysis
5. The SE team maintains sets of requirements of good quality. Success or and assessment techniques such as failure modes effects analysis (FMEA),
failure of a development effort hinges on how well the developers fault tree analysis (FTA), cost-benefit analysis, risk-benefit analysis, hazard
understand what the customer wants or the problem that is being solved by analysis, and more.
development of the system. Effective systems engineering translates the
needs and constraints of the customer into a set of valid system 10. The SE team effectively tracks safety and security design considerations
requirements that will satisfy the problem. Developers will have a clear and can tie it to them to requirements. Systems engineers should facilitate
understanding of the system to be built. The requirements will be the means to take a requirements-driven approach to mitigating identified
unambiguous and available to all stakeholders. risks. Trace matrices should provide live information on whether and how a
risk is being mitigated.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 18
PART 2 | Systems Engineering Beyond the Basics

Lessons learned in
systems engineering
There are hundreds of case examples of systems engineering gone
bad or systems developed in the absence of systems engineering at
all. But there are very few case studies of when systems engineering
is done well. Unlike software and mechanical engineering, the
discipline of systems engineering has no tangible output. Project
managers and executives who have cut corners or not performed
systems engineering do so due to a lack of perceived value. Theirs
are the projects that when a system is launched, miss the mark for
what the customer needed. Look no farther than the rollout of
Healthcare.gov, Microsoft Zune, Hubble Space Telescope, and the
London Ambulance Service Computer Aided Dispatch System.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 19
PART 2 | Systems Engineering Beyond the Basics

Resources to manage
increased complexity
Systems engineers are increasingly required to manage more
complex product development, and the Systems Engineering Body of
Knowledge (SEBoK) helps you stay current on relevant content areas.
But it’s also important to have the right tools behind you to more
effectively navigate complexities, maintain alignment across teams,
and get to market faster. Jama Connect® helps you more effectively
manage product and system requirements and bring people together
in a single place for increased visibility. You can more effectively
analyze impacts, track decisions, and ensure you’re building the
product that you set out to deliver. With our industry-leading solution,
you can do the following:

 Improve confidence. Trace requirements throughout the entire

development process. Spot risks faster and move forward with
confidence that you’re building exactly what’s intended.
 Enhance visibility. Get more visibility into the product
development process by monitoring relationships and
tendencies between various systems, teams, and activities.

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 20
  Bring products to market faster. Align your
teams, create more efficiency, and eliminate
expensive rework, so you can deliver
products on time and on budget.
 Transition into greater adaptability.
Competing in the future requires adaptability
so you can make changes fast. You can Are you ready to understand the complete
easily adapt Jama Connect to your specific
product development cycle and track
products and workflows to create an
intuitive experience that helps people get
requirements decisions and relationships
up to speed faster. more efficiently?
In this Requirements Traceability Benchmark, we examine how
traceability is measured, and the business practices that separate top-
quartile performers from the rest, including:
• Focus on Live Traceability™, not after-the-fact traceability
• Integrate traceable data across best-of-breed tools
• Make the Systems Engineering function data-centric
• Use model-based requirements to shorten and improve discovery
• Manage by exception

Learn more »

jamasoftware.com A Guide to Good Systems Engineering Practices: The Basics and Beyond | 21
Jama Software is focused on maximizing innovation success. Numerous firsts for humanity in fields such as fuel cells,
electrification, space, autonomous vehicles, surgical robotics, and more all rely on Jama Connect® to minimize the risk of
product failure, delays, cost overruns, compliance gaps, defects, and rework. Jama Connect uniquely creates Live Traceability™
through siloed development, test, and risk activities to provide end-to-end compliance, risk mitigation, and process
improvement. Our rapidly growing customer base of more than 12.5 million users across 30 countries spans the automotive,
medical device, life sciences, semiconductor, aerospace & defense, industrial manufacturing, financial services, and insurance
industries. To learn more, please visit us at jamasoftware.com.