PPI SyEN 80 – 19 August 2019
brought to you by
Project Performance International (PPI)
systems engineering training for project success
3.2 The Role of Requirements in an MBSE World
Copyright © 2019 by Lou Wheatcraft. All rights reserved.
The overall theme of the International Council on Systems Engineering (INCOSE) Requirements Working Group (RWG) for the 2019 International Workshop (IW2019), “The role of requirements in a Model-based Systems Engineering (MBSE) world”. was very popular among the attendees. Based on this theme there were ten presentations, resulting in a good cross section of perspectives and insights. While many good points were made over the four days, several key insights emerged. This article addresses five insights that resulted from the presentations and discussions.
The format of the sessions was such that questions and comments during the presentations were encouraged, resulting in interesting and engaging discussions. The presentations during the RWG sessions at IW2019 addressed the ongoing debate concerning the roles requirements play in a MBSE world:
Are text-based requirements still needed given the increased focus on diagrams, use cases, and models?
Can models be used to both help define requirements as well as implement those requirements in design?
Can models be used to improve the quality of requirement completeness, consistency, and correctness?
The focus of most of the presentations was on how systems engineering tools (requirements management tools as well as modeling tools) can be integrated together, resulting in an overall model of the system of interest that includes both text-based needs and requirements along with diagrams and models developed as part of the definition and design processes. The presenters showed how their organizations were able to practice information-based requirement development and management (I-RDM) at the beginning of the project and then use the resulting data and information as inputs to the Model-based Design (MBD) activities and artifacts (See Insight 4). The result demonstrated that the capability exists to link artifacts developed in one lifecycle phase to artifacts in other life cycle phases. Thus, needs can be linked to the stakeholders and concepts that were developed to address stakeholder expectations. Requirements developed and managed within a requirement management tool (RMT) can be linked to those needs as well as to the design models developed and managed within existing modeling tools, to the physical design, as well as to system verification and validation activities and artifacts.
Among the key insights that emerged during the presentations and resulting discussions that seem particularly significant to me are the following:
The concept of “duality” as applied to requirements and models. Depending on what is being done and what is being communicated, textual requirements and models are two sides of the same SE coin. Neither is solely sufficient – both are needed!
Requirements don’t just happen – they are a transformation from a set of needs that were transformed from a set of concepts that address a feasible solution to a problem.
The quality of the requirements is directly proportional to the quality of the set of stakeholder needs from which they were transformed. Likewise, the quality of the set of needs is directly proportional to the quality and quantity of the work done to define the problem, understand the stakeholder expectations, drivers and constraints, and risks – as well as the time and effort spent in maturing a feasible logical and physical concept (model) based on this information prior to documenting the needs.
Preliminary conceptual and physical design architectural models are both the source of the stakeholder needs and resulting requirements (design inputs) as well as the tools used to implement those same sets of needs and requirements, in the form of the design and the engineered system of interest (design outputs).
20th century systems engineering (SE) methods and practices are often not adequate to address the challenges of increasingly complex, software centric systems of the 21st century!
The following discussion explores each of the above insights in more detail.
A key insight from IW2019 was the concept of “duality” as applied to requirements and models:
1) Text-based requirements are important and cannot be replaced by diagrams/models.
2) Diagrams/models are also important and cannot be replaced by text-based requirements.
Both are different sides of the same SE coin! Neither is solely sufficient – both are needed!
For many ideas and concepts that need to be communicated; well-formed, text-based needs and requirements have been proven to be the most effective form of communication. Advantages2,5,6 of text-based requirements include the following:
Communication. There is still (arguably, there will always be) a sizeable audience who cannot interpret, do not understand, or who are not willing to work with, diagrammatic or other non-textual representations of needs or requirements, especially when the words used (technical jargon) are not intuitively obvious to the reader. These people, particularly the customers and users of the system, may not have been trained in language-based models or may not find the terminology used in some diagrams and models to be intuitive. When that is the case, effective communication4 has not taken place since the receiver of the message may not interpret and understand the message as intended by the sender and may well lose interest in the needs and requirements elicitation activities. On the other hand, text is universal. Of course, the text-based statements have to be well-written in such a way as to be clear, correct, and unambiguous; but then diagrams have even more potential to be unclear, incorrect, and ambiguous if they are poorly formed, defective, or the wrong meaning is assigned to them. Diagrammatic or model representation will almost always have to be supported by well written detailed textual statements in order for the representations to be understood unambiguously.
Power of expression. There is a wide variety of types of needs or requirements that must be expressed. Use cases, user stories, scenarios, diagrams, and models tend to focus on the functional architecture and may be capable of expressing functional, performance, and interface requirements, but are not presently well suited to expressing non-functional requirements that deal with the physical architectural elements associated with quality (-ilities), regulations, standards, and physical characteristics. Textual forms carry the universal power of expression of natural language for all types of needs and requirements.
Accessibility. Even when stakeholders are willing to spend the time to learn modelling languages such as UML and SysML or other model-based tools, the SE tools (including requirements management tools (RMT)) and modelling tools used to create and view the data and information represented by the model’s dataset are not readily available and assessable to all stakeholders. In many cases, access is restricted by the number of “seats” or “licenses” purchased. Being able to provide needs and requirements in an electronic document format (pdf, or common office application formats) allows the stakeholders to view the needs and requirements in applications that have been installed on their workplace computers. In addition, there are still managers who still prefer, and demand, printed, text-based documents, and will continue to do so for the foreseeable future.
Attributes. Both the need and requirement expressions include attributes2,3 that can be used to manage them as well as the system under development across all life cycle process activities. While modelling languages allow users to define an entity having the name “attribute” and link that entity to a need or requirement, few practitioners do so. Operational scenarios, use cases, user stories, and other diagrams used to represent needs or requirements are generally not conducive to appending a set of attributes.
Formal, binding agreement. Text-based requirement statements are more easily understood in a formal agreement or contract-based system development effort by a wider, and often, non-technical set of stakeholders including business management, project management, configuration management, contract administrators, and legal support. Use of “shall” or another term defined to have the same meaning, makes it clear that what is being communicated is formal, the statement is binding, and will be verified. To be part of a binding agreement, especially in a legal contract, the requirements must be expressed formally and configuration managed in a form that 1) makes it clear the statement is binding and 2) has the characteristics of well-formed statements and sets of statements as defined in documents such as the INCOSE Guide for Writing Requirements2.
System verification and validation. Most formal agreement (contract)-based product development and management processes include system verification (meets requirements) and validation (satisfies stakeholder needs in the operational environment) as formal processes that must occur prior to system acceptance and use. In highly regulated, safety critical industries such as the medical device industry, formal proof that the design outputs, including the product, meet the design inputs is needed prior to the product being released into the market. Currently, no other form, other than textual requirements, has been able to meet these characteristics.
Models and Diagrams
On the flip side of the SE coin, for many ideas and concepts that need to be communicated, models and diagrams have been proven to be the most effective form of communications. Advantages7 of models and diagrams include:
Defining and maturing concepts: Models and diagrams are excellent methods for defining and maturing a feasible concept by providing a context for requirements and are key to help ensure correctness, completeness, and consistency of both individual requirements and sets of requirements.
Source of Requirements: As part of concept maturation, functions are defined and relationships between those functions (interactions and interfaces) are identified. From this knowledge, functional flow block diagrams can be developed as well as context diagrams and interface diagrams. These can then be transformed into a functional architecture diagram which can, in turn, be transformed into a physical architectural diagram. These diagrams are an excellent source of requirements.
Key to understanding: Models and diagrams help facilitate communication by making complex systems and processes easier to understand. As the old saying goes: “A picture is worth a thousand words…”.
Identify and manage interdependencies. A key tenet of systems engineering is that the behavior of a system is a function of the interactions between the parts of the system. Tying these interactions together can result in an equation of dependent variables. From a change management perspective, a change in one of these variables results in a need to change one of the other variables. Managing these interdependencies within a model is much easier than in document-based approaches to SE.
Support simulations: Language-based models developed as part of design can be used to develop higher fidelity models that allow simulations of the system. With a simulation capability, design issues can be identified and corrected before actually building and coding the system – saving both time and money.
Requirements don’t just happen – they are a transformation from a set of needs that were transformed from a set of concepts that address a feasible solution to a problem.
The following definitions are based on the INCOSE Guide for Writing Requirements2.
Concepts, needs, and requirements apply to an entity, which could exist at any level of the model as shown in Figure 1. Entities apply to any single thing at a given level.
An entity is a single thing to which a concept, need, or requirement applies: an enterprise, business unit, service, system, or system element (which could be a product, process, human, or organization).
An entity satisfies concepts (validation), needs (validation) and requirements (verification) that are written for the entity as well as satisfy a problem or opportunity identified by the stakeholders. An entity is the subject of both a need statement (“The <stakeholders> need the <entity> to ……..”) and a subsequent requirement statement (“The <entity> shall ……”).
Figure 12: Transformation of concepts into needs into requirements
Defining and documenting concepts, needs, and requirements for an entity is more than just an exercise in writing; it is an engineering activity where the Requirements Engineer (RE) or Business Analyst (BA), through formal analysis, determines specifically what the stakeholders need the entity to do to satisfy a specific problem or opportunity. This formal analysis starts with the RE or BA engaging the customers, users, and other stakeholders in order to formalize a number of concepts which provide an implementation-free understanding of what is expected of the entity (design inputs) without addressing how (design outputs) to address the mission or business goals and objectives within defined constraints with acceptable risk. Concepts can be communicated in various forms including textual or graphical representations.
A concept is a written or graphic representation that concisely expresses how an entity will satisfy the problem or opportunity it was defined to address within specified constraints with acceptable risk.
There can be a number of concepts that apply to each entity, so it is useful to develop a minimal set of feasible concepts that define the expectations of all entities. It is also useful to provide some structure to the set of concepts. As illustrated in Figure 1, life-cycle concepts include operations concepts, acquisition concepts, deployment concepts, support concepts, and retirement concepts. Concepts, needs, and requirements are developed for entities at all levels. As stated under Insight 1, models and diagrams are very useful and important tools to help define and mature these concepts.
Based on these concepts, the RE or BA then defines a set of needs, that when met, will result in the concepts being realized.
A need statement is the result of a formal transformation of one or more concepts into an agreed-to expectation for an entity to perform some function or possess some quality (within specified constraints with acceptable risk).
Need statements are written from the perspective of what the stakeholders need the system to do; requirements are written from the perspective of what the system needs to do to meet the needs. Developing requirements is an engineering activity where the RE or BA, through formal analysis, determines specifically what the system must do to meet the needs using a formal transformation process involving either decomposition or derivation.
Requirements at one level are implemented at the next level of the system architecture via allocation. A child requirement is one that has been transformed (derived or decomposed) from an allocated parent requirement; the achievement of the complete set of children requirements will lead to the achievement of the parent requirement. At the system level, the achievement of the system level requirements results in the needs being achieved, from which the system level requirement was transformed.
A requirement statement is the result of a formal transformation of one or more needs or parent requirements into an agreed-to obligation for an entity to perform some function or possess some quality (within specified constraints with acceptable risk).
Figure 22 shows how the above concepts are related.
Figure 22: Entity-relationship diagram for customers, concepts, entities, needs and requirements terms
The quality of the requirements is directly proportional to the quality of the set of stakeholder needs from which they were transformed. Likewise, the quality of the set of needs is directly proportional to the quality and quantity of the work done to define the problem, understand the stakeholder expectations, drivers and constraints, and risks – as well as the time and effort spent in defining a feasible logical and physical concept (model) based on this information prior to documenting the needs and transforming the into requirements.
These activities are often referred to as scope definition. It is important to define and baseline scope in order to ensure the technical team has defined a feasible concept that has been agreed to by the stakeholders before documenting stakeholder needs and transforming them into requirements.
As shown in Figure 35,7, there is a lot of work to be done prior to writing requirements. Reference 5 goes into detail concerning each of the topics shown in this figure.
Figure 35,7: Scope Definition Activities
Preliminary conceptual and physical design architectural models are both the source of the stakeholder needs and resulting requirements (design inputs) as well as the tools used to implement those same sets of needs and requirements in the form of the design, specifications, and the engineered system of interest (design outputs).
Models and diagrams developed as part of scope definition and concept maturation result in a conceptual model of the system of interest. The conceptual model includes both diagrams and text-based needs and requirements. The conceptual model is an input to the design process. Rather than the design team starting with a set of requirements of questionable quality, they can start with a conceptual model based on an underlying data and information model1 and transform that model (design inputs) into a physical model (design outputs) as shown in Figure 4. In Figure 4, developing an underlying data and information model during scope definition and developing requirements is referred to as Information-based Requirement Development and Management (I-RDM). Using modelling as part of the design process is referred to as Model-based Design (MBD).
Figure 45,7: I-RDM + MBD = MBSE
If you combine the concept of I-RDM (design inputs) with the concept of MBD (design outputs), you get what the author advocates is what the intent of MBSE really is. Thus I-RDM + MBD = MBSE.
During scope definition and concept maturation, the focus is on the problem space (design inputs), defining the stakeholder needs and transforming these needs into a well-formed set of requirements which are linked to a conceptual logical architecture model of the system of interest. The quality of these requirements is high because they are based on a mature, feasible concept and the set of stakeholders needs that is consistent with that concept. To help prove feasibility, initial physical design related activities occur concurrently, maturing the system concept to the point that feasibility in the physical realm has been established, within identified drivers and constraints with an acceptable level of risk.
We are 19 years into the 21st century, yet many are still using 20th century SE methods and practices that often are not adequate to address the challenges of increasingly complex, software centric systems of the 21st century!
Today’s system development environment presents many key challenges7 as a result of increases in:
the role software has in the system architecture (software centric systems are the norm)
dependencies between key parts of the system
program and project risks
the number of programs that are over budget
the number of programs experiencing schedule slippage
One answer to these challenges is better systems engineering! Specifically, organizations need to7:
Incorporate systems thinking 1 into all phases of product development. Due to the complexity of today’s systems, we need to manage system development from a system thinking perspective at the systems level. We need to focus on interdependencies of the parts that make up the system and manage them at the system level. This is especially true when allocating performance and resources between parts of the system. In order to optimize the overall system, we may need to sub-optimize the parts that make up the system. This optimization must be managed at the system level.
Move software up in the system’s architecture hierarchy. Systems engineering in the 20th century tended to be mostly hardware centric and systems engineering practices worked well with physical architectures that were mostly hardware and mechanical. Today, many of the systems are software centric with system level functionality and performance implemented more in software than in hardware/mechanical parts. Because of this we need to move from a hardware-centric view to a software-centric view. Rather than decomposing a system into subsystems at the second level of architecture, a more appropriate approach may be to allocate system level requirements to hardware, mechanical, and software at the second level and then decompose them into an architecture that is appropriate to the domain and product line.
Communicate requirements at the proper level. Referring to Figure 4, a major issue with requirements is that it is common to include the how/build-to/code-to design output requirements in the what/design-to design input set of requirements. Or another way of referring to the issue is that it is common that “below the line” requirements are incorrectly communicated in the “above the line” set of requirements. When communicating the how (below the line/design outputs), often the what/why (above the line/design inputs) are not being communicated to the design team. This practice stifles innovation and can overly constrain the design team and force it into a design solution that may not be the best solution.
Recognize the importance of well-formed requirements and sets of requirements. Organizations need to recognize the importance of well-formed and managed requirements to the success of a program/project. Numerous studies8 have shown the increased risk to projects due to poorly developed requirements. As stated in the earlier insights discussion, organizations need to define scope and stakeholder needs before developing requirements, identify a feasible concept before developing needs and requirements, and use diagraming and modelling to help ensure completeness, consistency, and correctness of stakeholder needs and resulting requirements.
Forms of communication4. As part of the duality principle 2, organizations need to understand the role of both requirements and diagrams and models as well as which form is best to communicate a specific thing to a specific audience.
Summary and Conclusions
These insights are important to understand and implement in all our systems engineering activities to help successfully develop increasingly complex, software-centric systems. Being bound to the old 20th century, document-centric approaches to systems engineering is a recipe to failure. To be successful in the 21st century, we must move to a data-centric approach1 to systems engineering using both text-based as well as diagram and model-based communications, depending on what is being communicated and to whom. Using a data-centric approach, systems engineers should practice system engineering from the perspective that requirements, along with all work products (models, designs, documents, diagrams, drawings, etc.) generated during the performance of system life cycle process activities, are visualizations represented by underlying sets of data and information. To help ensure consistency, these sets of data and information need be able to be accessible and shared between the organizations involved in developing the system of interest. This sharing will help to ensure consistency, correctness, and completeness of work products developed across all system life cycle stages.
Referring back to the questions at the beginning of the article, the answer to all is YES! Based on the duality principle, depending on what is being done and what is being communicated, textual requirements and models are two sides of the same SE coin. Neither is solely sufficient – both are needed!
List of Acronyms Used in this Paper
BA Business Analyst
INCOSE International Council on Systems Engineering
I-RDM Information-based Requirement Development and Management
IS International Symposium
IW International Workshop
MBD Model-based Design
MBSE Model-based Systems Engineering
PM Project Management
RE Requirements Engineer
RMT Requirements Management Tool
RWG Requirements Working Group
SE Systems Engineering
SysML Systems Modeling Language
UML Universal Modeling Language
The author would like to acknowledge and thank all those who attended, presented, and actively participated in the discussions during the four days of RWG meetings at IW2019! It was all of you that made the sessions such a huge success!
INCOSE INCOSE-TP-2018-001-01, 2018, Integrated Data as a Foundation of Systems Engineering, prepared by the Requirements Working Group, INCOSE.
INCOSE-TP-2010-006-03, 2019, Guide to Writing Requirements, prepared by the Requirements Working Group, INCOSE.
Wheatcraft, L., Ryan, M., Dick, J. “On the Use of Attributes to Manage Requirements”, Systems Engineering Journal, Volume 19, Issue 5, September 2016.
Wheatcraft, L., Ryan, M. “Communicating Requirements – Effectively!” paper presented at INCOSE International Symposium (IS) 2018.
Wheatcraft, L., Ryan, M., Dick, J., Llorens, J., 2019. “Information-based Requirement Development and Management”, paper presented at INCOSE IS 2019.
Wheatcraft, L., Ryan, M., Dick, J., Llorens, J., 2019. “The Need for an Information-based Approach to Requirement Development and Management”, paper and poster presentation at INCOSE IS 2019.
Wheatcraft, L., Seilevel/Requirements Experts “Requirement Development and Management”, Three-day seminar workbook/slide deck.
Wheatcraft, L., “Triple Your Chances of Project Success Risk and Requirements”, paper presented at INCOSE IS 2011.
About the Author
Lou Wheatcraft is a senior product manager for Requirements Experts (RE)/ Seilevel, who educates organizations on the importance of developing and writing well-formed requirements and helps them implement Requirement Development and Management (RD&M) processes based on industry best practices. Lou has taught over 190 requirement seminars over the last 18 years.
Lou works with both government and industry clients. Lou has spoken at Project Management Institute (PMI) chapter meetings and INCOSE conferences and chapter meetings. Lou has published and presented many papers concerning requirement RD&M topics for NASA’s PM Challenge, INCOSE, INCOSE INSIGHT
Magazine, and Crosstalk Magazine. Lou is a member of INCOSE, Chair of the INCOSE Requirements Working Group, a member of the Project Management Institute (PMI), the Software Engineering Institute (SEI), the World Futures Society, and the National Honor Society of Pi Alpha Alpha. Lou has a BS degree in Electrical Engineering from Oklahoma State University; an MA degree in Computer Information Systems from the University of Houston – Clear Lake; an MS degree in Environmental Management from the University of Houston – Clear Lake; and has completed the course work for an MS degree in Studies of the Future from the University of Houston – Clear Lake. Lou is the primary contributor to RE’s blog on requirements best practices. The blog can be assessed at: http://www.reqexperts.com/blog.
Kind regards from the PPI SyEN team:
Robert Halligan, Editor-in-Chief, email: email@example.com
Ralph Young, Editor, email: firstname.lastname@example.org
René King, Managing Editor, email: email@example.com
Project Performance International
2 Parkgate Drive, Ringwood, Vic 3134 Australia
Tel: +61 3 9876 7345
Fax: +61 3 9876 2664
Tel Brasil: +55 12 9 9780 3490
Tel UK: +44 20 3608 6754
Tel USA: +1 888 772 5174
Tel China: +86 188 5117 2867
Copyright 2012-2019 Project Performance (Australia) Pty Ltd, trading as
Project Performance International
Tell us what you think of PPI SyEN. Email us at firstname.lastname@example.org.
- Systems thinking is a way of thinking about, and a language for describing and understanding, the forces and inter-relationships that shape the behavior of systems. This discipline helps us to see how to change systems more effectively, and to act more in tune with the natural processes of the natural and economic world. It is the discipline that integrates disciplines. Peter Senge, The Fifth Discipline (New York: Doubleday, 1990).
- In mathematics, a duality, generally speaking, translates concepts, theorems or mathematical structures into other concepts, theorems or structures, in a one-to-one fashion, often (but not always) by means of an involution operation: if the dual of A is B, then the dual of B is A. Such involutions sometimes have fixed points, so that the dual of A is A itself. Wikipedia.