Systems Engineering

A Guide to Good Systems Engineering Practices: The Basics and Beyond

By |

Systems Engineering

In this blog, we overview Part 1 of our eBook, “A Guide to Good Systems Engineering Best Practices: The Basics and Beyond” in which we discuss the fundamentals of systems engineering best practices, the “V” model,  the characteristics of good systems engineering, and lessons learned. To read the entire eBook, download it HERE.

A Guide to Good Systems Engineering Best Practices: The Basics and Beyond.

In the first part of this eBook, we discuss:

  • The fundamentals of systems engineering
  • The role of a systems engineer
  • Systems engineering process
  • The “V” Model of systems engineering

Part I: 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 engineers, electrical engineers, and a host of other specialized engineering disciplines. A systems engineer will focus on making each of the individual systems work together into an integrated whole that performs as expected across the lifecycle of the product.

What are the fundamentals of systems engineering?

In product development, systems engineering is the interdisciplinary field that focuses on designing, integrating, and managing the systems that work together to form a more complex system. Systems engineering is based around systems-thinking principles, and the goal of a systems engineer is to help a product team produce an engineered system that performs a useful function as defined by the requirements written at the beginning of the project. The final product should be one where the individual systems work together in a cohesive whole that meets the requirements of the product.

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.

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.

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 engineer must evaluate the complex system — as a whole — against the initial requirements and desired outcomes. Systems engineers have multi-faceted roles to play, but primarily assist with:

  • Design compatibility
  • Definition of requirements
  • Management of projects
  • Cost analysis
  • Scheduling
  • Possible maintenance needs
  • Ease of operations
  • Future systems upgrades
  • Communication among engineers, managers, suppliers, and customers in regard to the system’s operations

RELATED: The Complete Guide to the Systems Engineering Body of Knowledge (SEBoK)

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™.

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 Traceability are established, the systems engineer can set up continuous syncing between requirements and task management programs, thus automating traceability from requirements to user stories. This simple shift can help demonstrate the value of shifting from after-the-fact traceability to Live Traceability.

RELATED: Better Product Development: Five Tips to Achieve Live Traceability™

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.

RELATED: Adopting the EARS Notation to Improve Requirements 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 enable faster, less risky product development. The “V” diagram allows system engineers multiple viewpoints and opportunities to evaluate systems as they integrate with each other. This approach starts with the desired outcomes and objectives and then deconstructs them into individual systems and system components for the purpose of design. Once the requirements and design details are established, individual systems can be tested and evaluated, then integrated into the overall piece for testing and verification. As the systems are integrated and become closer to the final complex system, teams have multiple opportunities to validate and verify concepts, requirements, and design.

For the systems engineer, the “V” Model can give a clear roadmap that allows the breakdown of the complex system into smaller parts and then the reintegration and reassembly of the pieces into a cohesive whole. With systems broken down to individual components, traceability, requirements management, and testing and validation become more manageable. In addition, as the pieces are reintegrated into the whole system, the “V” Model allows for an iterative process that gives a clearer view into potential risks and helps troubleshoot problems. Systems engineering is a discipline that’s vital to the success of a complex system. By including systems engineers in all stages of product development and requirements management, teams can reduce risks, improve time to market, and produce better products that more adequately meet end user requirements.

Why is Live Traceability Essential? Given the complexity of products today, it takes multiple team members to weigh in on key decisions. And the number of decision points are only growing as products get more complex, making it even harder to adequately weigh all the options and trace their impacts. Learn more.

To read Part 2 of “A Guide to Good Systems Engineering Best Practices: The Basics and Beyond”, download the entire eBook HERE.


Decoteau Wilkerson
Latest posts by Decoteau Wilkerson (see all)