In order to stay competitive today, many organizations continuously improve their product development. To achieve this, requirements engineering has been identified as an important discipline, and many organizations look for improvements beyond that. In such cases, SE is often seen as the logical next step. But even though RE and SE do have a relationship, SE should be seen as an enabler, allowing the move from a multi-disciplinary work style to a trans-disciplinary one.
There is no “right” or "wrong" in practicing RE and SE. Both fields are evolving, and organizations are practicing both disciplines in different ways. It is crucial to be clear within collaborative groups to create a common understanding. This group can be a department, an organization, or even people working across organizations. If there is no clear understanding on the organizational practices, it is likely that someone will drop the ball.
Also, a word of caution: Just because there are official definitions of RE and SE, this does not mean that everyone is aware of these. In fact, the official definition is often the smallest common denominator, as there is sometimes disagreement among the individuals who write standards. A good example is requirements management, which according to the ISO definition is part of requirements engineering. However, in the USA, it is common to use the term "requirements management" for what is RE in this article.
This article is directed at practitioners who have solid experience in RE, and plan to move from there to a SE perspective in their organization. The intention of this article is to create awareness of the relationships between the various disciplines, and to ensure that all understand the new role that RE has to take on. We provide some hands-on advice on what to look out for when evolving the development approach.
Introduction
All organizations are faced with requirements for their products. Sometimes requirements are not explicitly stated, but they exist nevertheless. Therefore, organizations often start by practicing requirements engineering in a more rigorous manner when they strive to improve their product development. Other disciplines may follow, like design, production, quality, or project management, to name just a few.
Depending on whether this is seen as strategic or not, the result is either a well-structured approach, or a patchwork, that nevertheless gets the job done. All this happens in the context of regulations, customers, contracts or just competitive pressure.
Systems Engineering provides a framework for a systematic evolution of product development, especially if functional safety is a concern. However, without proper understanding, sponsorship and resources, this transition my not reach its full potential. Or, even worse, the effort could vaporize. The authors encountered enough examples from the field where the result did not meet expectations.
Let's start by looking at established definitions of RE and SE and to explore their relationship.
What do the Standards say?
Let's take a step back and look at the relevant standards. Requirements engineering is defined in ISO/IEC/IEEE 29148:2011, "Systems and software engineering – Life cycle processes – Requirements engineering" [29148]. There it is defined as an "interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system, software or service of interest."
There are other definitions that make the relationship of RE to SE explicit. [Young], for instance, defines Requirements Engineering (RE) as "an area within the broader fields of systems and software engineering that focuses on understanding customer needs and expectations, requirements analysis and specification, requirements management, and requirements verification and validation".
The standard also defines requirements management as part of requirements engineering. This can be confusing to US-American practitioners, who often use the term requirements management for what is covered by [29148]. The standard defines requirements management as "activities that ensure requirements are identified, documented, maintained, communicated and traced throughout the life cycle of a system, product, or service".
Systems Engineering is defined in ISO/IEC/IEEE 15288, "Systems and software engineering – System life cycle processes" [15288]. As is to be expected, the two standards reference each other. This allows us to explore the relationship between the two disciplines, as it is understood by the standards. Note that you'll often encounter references to ISO/IEC 12207 as well, which is similar to [15288], but for software, not systems.
Both standards explicitly state that there is a relationship between SE and RE. The standards strive for a harmonization of the two, as stated in the foreword of ISO 15288: This standard was developed to "achieve a fully harmonized view of the system and software life cycle processes", which include RE. Later we will see that ISO 29148 even makes the relationship explicit by mapping processes.
RE is often considered a sub-discipline of SE, but this view is misleading. This line of thinking suggests that we can achieve SE by simply expanding on our RE activities. Disciplines can be hierarchical, but there are other relationships too. Let's have a closer look.
Disciplines
Developing complex products requires a joint effort of multiple disciplines, from mechanical engineering to social sciences. Collaborating on such an endeavor is a multi-disciplinary approach, if each discipline contributes their work to the project as a whole [Ertas]. This is shown in the figure below to the left: The various engineering disciplines do communicate (circular arrows); however, they contribute to the product development, without taking the perspective of the other disciplines into account.
But a better product results from an inter-disciplinary approach, where the various disciplines optimize their contributions with each other, before contributing to the product development. In other words, the contribution to product development is made taking all relevant disciplinary perspectives into account. This is also shown in the figure to the right. Both figures are taken from [Ertas].
It is also possible to go one step further by using a trans-disciplinary approach. This involves not only "crossing engineering disciplinary boundaries but also requires crossing families of disciplinary boundaries (engineering, social science, natural science, and humanities)" [Ertas].
Systems Engineering is the enabling discipline being described above, which pushes development from a multi-disciplinary to an inter-disciplinary, or even trans-disciplinary approach. How this can be practiced is described by [Young], where an iterative process involving requirements processes and systems engineering processes leads to a more robust architecture.
Understanding the Relationship between RE and SE
So far we recognized that RE and SE are two disciplines (of many) that are practiced in product development, in an inter- or trans-disciplinary approach. We also established that they have a relationship to each other. Let's consult the standards again, in order to understand this relationship better.
Figure 1 has been taken from [15288]. Conveniently, [29148] provides a mapping between the two standards in Annex C. One caveat: The latest [15288] was released in 2015, [29148] in 2011. Therefore, the table in Annex C refers to 15288 release in 2008. Rather than showing the old processes, the highlighting applies the content from Annex C to the revised process list in the current [15288].
Figure 1 highlights those processes that [29148] demands. Let's explore what areas need to be covered, besides RE:
Technical Processes: RE is concerned with technical processes. But SE includes additional processes that are not part of RE. These cover design and implementation, as well as a number of life cycle processes covering aspects like operation, maintenance or disposal.
Technical Management Processes: These processes relate to the discipline of project management and cover aspects like planning, risk management and quality assurance, amongst others. They are concerned with managing the resources and assets of the organization. Almost all organizations perform at least some of these processes, but are not aware that they are actually part of SE.
Organizational Project-Enabling Processes: These processes align the work with the organization's strategy. After all, the development should align with the company's objectives and eventually produce value for the shareholders or owners.
Agreement Processes: Last, the agreement processes are concerned with managing suppliers (downstream) and customers (upstream).
Looking at the list of SE processes, it is also clear that many organizations are already practicing them, sometimes unaware that these are orchestrated by SE. Not being aware of this can obviously create problems: Such organizations found a working mode over the years that allows them to (hopefully) successfully develop and build systems. The catch: the purposeful drive towards an inter- or trans-disciplinary workstyle that is created by SE is missing.
The cost of evolutionary growth
Not being aware of the role of RE in the SE lifecycle processes is not a problem per se: One could argue as per the old proverb: "Never touch a running system". The authors agree with this point of view: A functioning organization should only be changed if there is a reason for it. Unfortunately, there are more reasons than ever that trigger the need to rethink product development. These include:
New regulations: an important driver for changes are regulations, in particular those related to functional safety (i.e. those based on IEC 61508, like ISO 26262).
Innovation: Some organizations that have been building almost identical products for a long time, and for that, existing processes were sufficient. When they try new avenues for innovative products, they realize that the current processes don't give them enough confidence with respect to compliance, quality or other criteria.
Quality: This is also a strong driver, related to innovation: Customers are increasingly expecting higher quality, which they often quantify. Established processes may not provide the means for tracking and ensuring the required quality.
Time to market: Lastly, established processes are sometimes hard to accelerate, especially when they are linear to a large degree. New processes and approaches are required to speed up development, for instance by parallelizing activities.
Product Errors and Defects: Sometimes you develop a system or product that does not meet market needs or solve the problem it was supposed to because of a lack of systems engineering and systems thinking.
A New Way of Thinking
Organizations that want to switch to true systems engineering should be aware of the implications. The cost of this change depends – obviously – on the state of things in the organization. But the most fundamental question is: Does the organization plan on practicing Systems Engineering as an enabler for inter-disciplinary work? Or is it sufficient to be compliant (e.g. according to [15288]), but sticking with a multi-disciplinary approach?
The answer to this question is not obvious: An inter-disciplinary approach (enabled by SE) can create spectacular productivity and amazing products. An example for this approach is the development of the WIKISPEED car [SGT01]. This car was a successful contestant to the Progressive Insurance Automotive X-Prize contest. The car was designed and built in 3 months to produce a street-safe, fuel-efficient car. Subsequently the car is improved, built and sold on a one-week product cycle. The approach behind this is called "Agile in Hardware". We'd argue that this achievement would be impossible without a holistic approach and trans-disciplinary collaboration, for which SE is an enabler.
Towards inter-disciplinary SE
It should be clear that practicing SE as an enabler for inter-disciplinary work can provide significant benefits. It should also be clear that this approach is not necessary in order to successfully develop products. Many organizations develop innovative and successful products with a multi-disciplinary approach, where RE is just one of a set of disciplines. After all, implementing SE has its cost.
Let's start with the preconditions that should exist before trying to establish SE an enabler for inter-disciplinary work:
Management Buy-In: A migration to SE must be backed by the organization's leadership, as it affects many areas in a company, certainly much more than just product development (see Figure 1). It is crucial that management understands all aspects of this transition: benefits, risks and cost.
Sponsorship: Sponsorship goes hand in hand with the previous item: Most changes, but certainly a change like this, are expensive and take a long time. There will almost certainly be a temporary productivity loss, while the organization goes through the transition.
Acknowledgment of all stakeholders: Even if buy-in from management exists and resources are provided, it is important to understand all influential stakeholders and to make sure that they support this effort. At a minimum, their concerns must be acknowledged. Unfortunately, it is very easy to disrupt a transition like this with politics. This is a large risk, and key stakeholders must be carefully managed.
Solid existing processes: As has been shown earlier, SE is an enabler for inter-disciplinary work that requires a large number of processes. Introducing SE to an organization that already performs those processes well is a good starting point for this transition. This aspect is not crucial, but helps. There is the notable exception of young organizations: With the right people, start-ups can begin with a holistic SE view from day one.
Competent technical leadership: The challenges of the proposed transitions should not be underestimated, and the key people must have the technical competence, as well as leadership skills. But it does not end after the transition is complete (if it is ever complete): Once an organization practices inter-disciplinary development enabled by SE, it needs ongoing technical leadership, the Systems Engineer. This is a role that – obviously – only exists in organizations that do SE (real or imagined). This role is crucial and demands a closer look.
The Role of the Systems Engineer
Paul Schreinemakers, former technical director of INCOSE, compares the Systems Engineer to the role of the CTO of an organization [Schrein]. It is an inside-facing technical role, but one that requires strong leadership skills, as well as a broad understanding of the inter-disciplinary concerns in an organization.
For an organization to actually embody SE, it needs to create this role, and fill the position with a competent and experienced Systems Engineer. Organizations that already have a Systems Engineer should make sure that this person has the right definition of SE, as well as the technical and leadership competence to oversee the planned changes.
Another benefit of employing a good systems engineer is that this person will also create social and engineering communication across the engineering teams. Enabling these critical interactions will enhance the quality of work done at the intersections of the engineering disciplines.
Good Systems Engineers are rare, and [Schrein] also covers the question on how to train individuals and organizations with respect to SE skills.
Conclusion
SE is an enabler for an inter- and trans-disciplinary workstyle, which can bring significant improvements, even for organizations that already successfully develop products. But especially for such organizations, it is important to realize that SE cannot be achieved by simply expanding RE: RE is only one discipline that is orchestrated by SE.
Not pushing for SE puts organizations at a disadvantage. That does not mean that it is wrong to practice multi-disciplinary product development, with RE being one discipline. But in the long run, staying at that point may reduce competitiveness. In some cases with the complexity of today's systems, not doing SE can lead to system or product integration failures that teams working within siloed disciplines failed to uncover.
Seeing SE as a separate discipline that enables inter- and trans-disciplinary practices can provide a significant productivity boost, when implemented correctly. Of course, this requires change, which is expensive, risky and creates temporary friction. Whether this change is justified depends on many things, but should ultimately be a strategic decision that is supported and understood by the leadership.
References
- [SGT01] David Socha, Tyler C. Folsom, Joe Justice: “Applying Agile Software Principles and Practices “, for Fast Automotive Development, Proceedings of the FISITA 2012 World Automotive Congress (2012), pp 1033-1045
- [Young] Ralph R. Young: "Effective Requirements Practices", Addison-Wesley (2001)
- [Schrein] http://formalmind.com/blog/paul-schreinemakers/
- [15288] https://www.iso.org/standard/63711.html
- [29148] https://www.iso.org/standard/45171.html
- [Ertas] Atila Ertas: “Understanding of Transdiscipline and Transdisciplinary Process”, Transdisciplinary Journal of Engineering & Science Vol: 1, No:1 (2010), pp.55-73
Dr. Michael Jastram is an expert model-based systems engineering (MBSE), with a focus on requirements. He has over 20 years experience in software development and requirements engineering, which he regularly shares as author and public speaker. Amongst other things, he publishes weekly updates on Systems Engineering Trends [German] and monthly updates on Requirements Engineering [English].
Michael is a leader in open source requirements management, being project lead of the Eclipse Requirements Modeling Framework. He is also a strong advocate of open standard and actively contributes to the OMG Requirements Interchange Format (ReqIF).
Today, he is founder and principal systems engineer of Formal Mind GmbH, a service provider in Open Systems Engineering.
You can connect digitally with Michael via his Blog [en] | Blog [de] | Twitter | LinkedIn | Xing.
Cary Bryczek leads the Jama team as the Principal Solutions Architect for our highly regulated customers in the Aerospace and Defense and Medical Device industries. Her role includes creating collaborative systems engineering solutions within Jama's software that increases stakeholder involvement and reduces decision making time. Her background in systems engineering from working on a wide variety of programs in defense, intelligence, aerospace, and healthcare lend her a broad perspective on approaches to requirements engineering for large and small organizations.
With over 15 years of experience as a solutions engineer, Cary has worked with companies such as Lockheed Martin, Medtronic, PTC, Defense Intelligence Agency, Abbott Labs, NASA, Food and Drug Administration and is a participating member of INCOSE, AAMI and IEEE.