This is a multiple part blog:
This part 1 introduces the overall topic of communicating requirements and addressed communication of requirements from several perspectives: traditional systems engineering, model-based systems engineering, and Agile.
In part 2, I address basic definitions of requirements from each of these perspectives and discuss the various types of requirements that need to be communicated.
In part 3, I introduce the basic communications model from a requirements perspective.
In part 4, I discuss the advantages of text-based requirements vs alternate forms of communicating requirements.
In part 5, I conclude the series with a discussion of characteristics of well-formed requirement statements, sets of requirements, and attributes.
Introduction/Background
Requirements are the language used to communicate stakeholder needs for a system of interest to developers, designers, builders, coders, testers and other stakeholders. Increasingly, the debate is about which means (form and media) of communication is the best way to communicate requirements. Forms of communications include: verbal, text, diagrams, and models. These forms can be communicated using various types of media: face-to-face, phone, email, text-messages, printed documents, electronic documents, electronic tool(s) database or model. Depending on the idea or concept, the specific system type, domain, culture, people, and processes within a specific organization, one means of communications is often advocated (with a lot of passion in many cases) over the other forms.
This issue is often debated between three principal groups: “traditional” systems engineering (SE), model-based SE (MBSE), and Agile.
Traditional Systems Engineering
SE is an interdisciplinary approach and means to enable the realization of successful systems. Traditional SE follows well defined product lifecycle stages, separated by gate reviews, where the problem is identified and stakeholder needs are defined for required functionality, performance, and quality while considering the complete problem: cost and schedule, risks, training and support, test, manufacturing, operations, maintenance, and disposal. The stakeholder needs are baselined and transformed into a set of system requirements. These requirements are implemented in the form of logical and physical architectures. Individual diagrams and figures may be used as part of requirements analysis. Requirements are allocated to parts of the architecture at the next level. This process repeats iteratively and recursively in a top-down fashion for each level of the architecture. This results in a set of requirements for each part at each level of the architecture. All the requirements at one level are traced to a source and/or to a parent requirement at the previous level.
These sets of requirements are developed in either an office application or a requirements management tool, from which the requirement documents are generated. The set of requirements is managed formally in the form of a configuration controlled document that can be passed on to external developing organizations in the form of a contract. The requirements may or may not be based on an underlying data and information model of the system.
The baselined requirements are implemented by a developing organization (internal and external) via design, the parts are built/coded, verified to have met the requirements for that part, and integrated together bottom-up to form the system. The completed physical system (software application, hardware, or hybrid software/hardware) is verified to have met the system level requirements and validated to have met the stakeholder needs in the operational environment.
Model-based Systems Engineering (MBSE)
MBSE enhances the practice of SE by using language based diagrams and other visualizations of the system of interest to better understand complex systems and how the various parts of the system interact. The ultimate goal of MBSE is for requirements, diagrams, and other visualizations to be managed using an integrated data and information model of the system of interest. MBSE is a concept that is evolving—currently the concept is not yet well understood and practiced consistently by all. Some organizations use diagrams and models from the beginning of a project to better understand the problem, stakeholder needs, and define a feasible concept that will realize those needs. It is from these activities and knowledge that a set of requirements are defined. Once the requirements are baselined, design can then continue by adding more detail to the logical model which is then transformed into a physical system that is delivered to the customer in accordance with the process described above for traditional systems engineering.
For others, the practice of MBSE is really model-based design (MBD). In this context, the modeling process starts with a baselined set of system requirements, often text-based, and often with no underlying data and information model. Like traditional SE, the requirements document is under configuration control and is part of a contract between the customer and the developing organization. The developing team uses diagrams and models to analyze the requirements. Based on this analysis, the modeling team iteratively and recursively defines an overall logical architecture of the system which is then transformed in to a physical system that is delivered to the customer per the process described above for traditional systems engineering.
Within the MBSE world, there is a lot of debate concerning the form of the requirements and the media used to communicate those requirements. Are the diagram visualizations that make up the model sufficient to communicate requirements or are text-based requirements needed as well? A popular modeling language, SysML, includes an entity called “requirement” and includes several names for various relationships between requirements as well as between requirements and other entities that make up the model. If an entity in the model is named a requirement and that entity linked to other entities that make up the model, is this an acceptable form of documenting requirements? For MBSE, the requirements, no matter the form, are part of the overall data and information model of the system.
Agile
Agile is also an interdisciplinary approach and means to enable the realization of successful systems. Those that use Agile development are guided by the “Manifesto for Agile Software Development” (Agile Manifesto, 2001). Agile is most commonly used for software application type projects, but in certain cases is also being used to develop integrated hardware, mechanical, software systems. In these cases, Agile has been used successfully in the practice of both traditional SE as well as MBSE. Agile is used for projects where the customer and developers can work closely together in a collaborative environment, the system under development can be delivered incrementally, with each increment delivering value to the customer, and where the enterprise infrastructure and processes supports an Agile development approach. As was described for traditional SE, the Agile team focus is on understanding the problem, stakeholder needs, defining a feasible concept that will realize those needs and expectations, and delivering a useful system that solves the problem and stakeholder needs. The big difference is the form and media requirements are communicated between team members. The focus tends to be on functions and features as defined in user stories and resulting use cases, and various diagrams similar to those used in MBSE. The agreed-to set of use cases and diagrams represent the concept that will be implemented. Many practicing Agile advocate that they go directly from concept to useable software and/or hardware that adds value for the customer. This is in contrast to the traditional SE lifecycle approach which proceeds from concept to requirements to design to system.
———————
In part 2 of this blog series, I address basic definitions of requirements from each of these perspectives and discuss the various types of requirements that need to be communicated.
Comments are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
