This is part 1 of a 2 part series

Systems engineering (SE) can help improve product development, especially for today’s increasingly complex products that are really systems of hardware, software and connectivity. It is an interdisciplinary practice that helps ensure products meet all stakeholder requirements and can be delivered on time with high levels of quality. Defining and managing requirements from the business, customers and regulatory bodies is a foundational element of SE. However, it can be difficult for product teams to know how to go about starting or expanding an SE program.

Three questions can help frame an SE project, whether it’s new or an expansion of an existing program:

  1. What are we doing?
  2. Why are we doing it?
  3. How do we know when we’re done?

Stepping back and asking these questions helps align team members who may be used to focusing only on their piece of the overall project. It gets the entire team thinking about the product – the system – as a whole, with the “what” and “why” forming the foundation for starting to build the requirements that will be used to drive development. Defining project completion sparks conversations around what needs to take place before the product is ready for customer delivery – integration, testing and rework – allowing for more achievable and realistic delivery dates.

An organizational approach to developing SE processes and standards is essential for implementing SE. Team members must be given adequate training to understand their roles and responsibilities. Selecting tools such as those for requirements management (RM) needs to be undertaken thoughtfully, with a clear expectation of results and what it will mean to the project.

Why Add SE to an Organization?

Many organizations that have not adopted SE have traditional hardware, software and project management organizations, each of which may lack the ability to fully understand the needs and expectations of the overall project. SE teams bring in the concept of systems thinking and ask questions such as: What are we building? How are we going to build it? What regulations/standards do we need to meet? How are we going to maintain it in the field? How are our customers going to use it? How will it be retired/replaced?  They drive architecture without bias to hardware or software, understand the regulations and standards that impact the system and take cybersecurity into consideration throughout the entire project lifecycle.

Their objectivity allows systems engineers to better analyze trade-offs by looking at the most effective way to get something done with the least impact to deliverables, schedules and functionality and the best way to update the system once it’s put into service. This often involves an examination of hardware versus software options. A good example is the approach taken by Tesla to perform over-the-air (OTA) updates for their vehicles rather than investing in dealer service locations to perform manual updates.

Another area where systems engineers add value is their ability to look at the implications of future technology changes. For example, if a particular technology or process changes, how much of a redesign will be required? Are there design changes that can be made today to ease the introduction of new technologies in the future?

Finally, SEs examine the allocation of requirements to lower-level subsystems and ensure that they are clearly laid out so that team members doing the implementation have a complete understanding of what they’re doing and what they’re expected to deliver.

Why Requirements Management is Key

Successful SE projects hinge on getting the requirements right and managing them effectively as part of the entire development process. Requirements start with accurately defining the product based on capturing users’ needs so that the end product meets their expectations, and ensuring all standards relevant to the product and its industry are incorporated.

The project needs to be examined for completeness so that all parts of the system are defined and everyone involved in the project has all the requirements needed to complete their tasks. There has to be an understanding of how subsystems will be integrated into larger systems and interfaces defined to external systems.

Verification and validation (V&V), always important within regulated industries, are becoming just as important to commercial industries. Development teams need to verify that requirements were defined and met correctly, and also validate that the product does what it is intended to do.

Product lifecycle considerations include the ability to support products once they are in service, including the ability to easily update them, and plans for product sunset.

SE and RM are very useful in planning for audits as they allow organizations to demonstrate that they have gathered the necessary requirements, allocated them correctly and traced them from the upper to lower levels of the system.

Figure 1 illustrates essential SE activities that need to be performed within development organizations.

Figure 1. Essential SE Activities

 

System Requirements

Requirements define the capabilities and characteristics a system must provide in order to satisfy stakeholder needs and requirements. Since the primary stakeholder is the end customer or user, the overarching objective is to ensure that the particular needs or requirements identified by the user are adequately addressed by the requirements established for the system.

Figure 2 shows the role of system-level requirements as the primary driver of the development process. At the outset, system-level requirements form the basis of the main system architecture and design activities, as well as helping define system integration and verification activities. They act as a reference for validation and stakeholder acceptance. At the same time, requirements become the main communication tool among parties. For example, subcontractors can be provided with requirements to give them specific direction on what to build; or customers can be asked to review requirements to ensure they accurately describe what is being built.

Figure 2. Requirements play a major role in SE

 

 

Requirements attributes. A requirements attribute is a characteristic of the requirement that is not intrinsic to the requirement itself but is critical to its ability to be met. Attributes define the requirement’s relationships to the rest of the development effort. Figure 3 outlines types of attributes and their relationship to processes and team members.

Figure 3. Types of requirements attributes

 

This is just a sample of the attributes that can be used with requirements. The attributes are used by the SE to identify roles and tasks associated with the requirement. For the design teams and V&V team, the attributes provide additional information they need for their tasks.

Requirements traceability. Requirements traceability is defined by numerous standards and publications:

  • The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another. (Systems and software engineering – VocabularyISO/IEC/IEEE 24765:2010(E). 2010-12-01)
  • The identification and documentation of derivation paths (upward) and allocation or flow-down paths (downward) of work products in the work product hierarchy. (Systems and software engineering – Life cycle processes – Requirements engineering. ISO/IEC/IEEE 29148-2018)
  • Identification and documentation of the derivation path (upward) and allocation/flow-down path (downward) of requirements in the requirements set (ISO/IEC/IEEE 29148-2018)
  • Discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks. (Gotel, O.C.Z.; Finkelstein, C.W. (April 1994). An analysis of the requirements traceability problem. Proceedings of IEEE International Conference on Requirements Engineering. pp. 94–101)

Taken together, these definitions illustrate the various ways requirements fit within the project and their relationships to other elements of the project and of the overall system.

Figure 4 illustrates how requirements are traced both upwards to stakeholder needs and downwards to lower-tier specifications or system definition artifacts. They are traced to pre-requirements activities such as stakeholder expressions of specific capabilities, characteristics, constraints or quality factors; and to post-requirements relationships such as models, analysis results, testing and documentation.

Traceability of requirements is undertaken to ensure all customer requirements are addressed by the systems requirements; all system requirements are allocated to sub-systems; and requirements are decomposed as needed to address the higher-level requirements.

Figure 4. Requirements traceability

 

Model-Based Systems Engineering. For projects that are highly complex, Model-Based Systems Engineering, or MBSE, can improve the process of establishing requirements and using them to create system-level architecture and drive design activities. MBSE is an evolution of SE methods that uses models in place of document-centric design artifacts. For a deeper dive into MBSE, read Is Model-Based Systems Engineering for You?

Paul Kostek

Paul Kostek

Advisory Systems Engineer

Paul is an Advisory Systems Engineer with Base 2 Solutions in Bellevue Washington. He has worked in a variety of fields such as aerospace, defense, medical devices and e-commerce. He is Experienced in requirements, architecture, risk management, interface definition, verification and project planning.