In my blog: INCOSE Guide to Writing Requirements updates made at IW 2015, I mentioned the concept of layers of requirements above the system level and provided the following diagram that showed the layers, but I did not elaborate on these layers. This diagram and an explanation of the diagram is included in the updated Guide.
Figure 1. Transformation of needs into requirements (Ryan, 2013).
I received comments questioning the need for having layers of requirements above the system level. This blog includes my response to this question and provides a practical example by Dr. Mike Ryan, co-author of the Guide.
Studies have shown that a main reason projects fail is because they failed to understand the drivers and constraints dictated at these “non” system layers. From a systems thinking viewpoint the systems (products) are being developed within the infrastructure of the organization developing the system as well as the infrastructure of the customer of the system for systems being developed for another organization. It is at these layers where business rules and requirements reside as well as standards.
No mater how your organization is structured, needs and requirements exist at a number of levels above the system (product) level. There is an enterprise view in which enterprise leadership sets the enterprise strategies in the form of a Concept of Operations (ConOps) or Strategic Business Plan (SBP); a business management view in which business management derive business needs and constraints as well as formalize their requirements; a business operations view in which stakeholders define their needs and requirements; and a systems view in which the system is defined in logical and physical views. Subsequently, there are views at the lower-level of the subsystem and other system elements. Note that a system may comprise a number of elements including products, people, and processes. Together these elements enable a needed capability for the organization.
Enterprise Layer
The enterprise has a number of strategies that will guide its future. From our perspective, a system has its genesis in the ConOps or SBP that communicates the leadership’s intentions with regard to the operation of the organization—in terms of existing systems and systems to be developed. At this layer the ConOps, or SBP, defines the enterprise in terms of ‘brand’ and establishes a mission statement and corresponding goals and objectives, which clearly state the reason for the enterprise and its strategy for moving forward.
Business Management Layer
The Business or Mission Analysis Process begins with the organization’s mission or vision statement, goals and objectives communicated by the ConOps or SBP. Business management uses this guidance to define business needs, largely in the form of a life-cycle concepts, which capture the business management’s concepts for acquisition, development, marketing, operations, deployment, support, and retirement. These concepts are then used to define specific needs for that layer.
The business needs contained in the life-cycle concepts are elaborated and formalized into business requirements, which are documented in the Business Requirements Specification (BRS) or Business Requirement Document (BRD). The process by which business needs are transformed into business requirements is called mission analysis or business analysis.
Business Operations Layer
Once business management is satisfied their needs and requirements are reasonably complete, they pass them on to the business operations layer. Here, the Stakeholder Needs and Requirements (SNR) Definition Process uses the ConOps or SBP and concepts contained in the life-cycle concepts as guidance. The Requirements Engineer (RE) or Business Analyst (BA) leads stakeholders from the business operations layer through a structured process to elicit stakeholder needs—in the form of a refined OpsCon or similar document and other life-cycle concepts (see Figure 1). The RE or BA uses a structured process to elicit specific needs, as documented in user stories, use cases, scenarios, system concepts, or operational concepts. (Note that the term “stakeholder” above refers to stakeholders internal to the enterprise as well as external stakeholders that are part of the supply chain that supports the enterprise.)
Stakeholder needs are then transformed into a formal set of stakeholder requirements, which are documented in the Stakeholder Requirement Specification (StRS) or Stakeholder Requirement Document (StRD). That transformation is guided by a well‐defined, repeatable, rigorous, and documented process of requirements analysis.
System Layer
At the system layer, in the System Requirements Definition Process, the requirements in the StRS are then transformed by the RE or BA into System Requirements, which are documented in the System Requirement Specification (SyRS) or System Requirement Document (SyRD). As in the previous process, the RE or BA accomplishes the transformation of needs into requirements using various requirements analysis methods such as functional flow diagrams, timeline analysis, N2 Diagrams, design reference missions, modeling and simulations, movies, pictures, states and modes analysis, fault tree analysis, failure modes and effects analysis, and trade studies.
Relationships between layers
At each layer, the resulting requirements will be documented, agreed-to, baselined, and will be put under configuration management. Note that some organizations may prepare individual life-cycle concepts for each of a number of systems that are developed to meet the business needs.
Once a set of requirements has been documented, agreed-to, and baselined at one layer they will flow down to the next layer as shown in Figure 1. At the next layer, the requirements are a result of the transformation process of the needs at that layer as well a result of the decomposition or derivation of the requirements from the previous layer. As such, a number of SyRS or SyRD requirements may be either decomposed from (that is, made explicit by the requirements of) or derived from (that is, implied by the requirements of) the StRS or StRD. The same is true at the subsystem or system element layer, where a number of the subsystem or system element requirements may be either decomposed or derived from the SyRS or SyRD. In all cases, for each layer shown in the figure, the set of requirements can be traced back to the requirements at the previous layer from which they were either decomposed or derived. This process continues for the next layer of system elements.
How requirements are expressed differs through these layers, and therefore so do the rules for expressing them. As requirements are developed – and solutions designed – down through the layers of abstraction, we expect statements of requirement to become more and more specific. At the highest level, the ideal requirement is not specific to a particular solution, and permits a range of possible solutions. At the lowest level, statements of requirement will be entirely specific to the selected solution. It is important to note that the form of requirements at one layer may not be appropriate for another layer. For example, at the business management layer, there may be a requirement that all products are “safe”. While this is a poor system requirement, it is appropriate for the Business Management layer. At the next layer, business operations, there will be less ambiguous and more detailed requirements that define safe. These requirements apply across all product lines of the enterprise. At the system layer, more specific safety requirements will be developed for that specific system. These requirements will then be allocated to the system elements at the next lower layer.
Example of layers of requirements above the system level
The key point is that when an organization develops a system, they need to adapt to system thinking and address the macro system in which the system under development must work. Dr. Mike Ryan illustrates this very clearly in the following example. Dr. Ryan is the originator of the concept of layers above the system level. He is from the School of Engineering and IT (SEIT) at the University of New South Wales, Canberra, Australia and is chair of the INCOSE Requirement Working Group.
“The three levels are necessary because they represent three significantly different perspectives that must be activated in a top-down manner.
Consider a wood-felling company whose management has just returned from a 1930s trade show where they witnessed a demonstration of the revolutionary chainsaw that has been introduced to the market by Andreas Stihl’s new company. Although the ability to cut down trees at a greater rate is very attractive, the company cannot simply sit down and write a system specification for the procurement of chainsaws.
Further, they cannot even ask stakeholders at the business operations level to describe what they want out of a new chainsaw capability in the form of stakeholder needs and requirements. The current operational managers are used to managing axe men who are not able (and probably not willing since they are going to be re-trained at best and, at worst, let go) to describe in any manner how the new tool is to be operated, since they have no familiarity with the operating procedures, training, safety or the maintenance necessary for the new equipment. Similarly, the logistics staff at the business operation level will know, in considerable detail, current logistic information such as the number of axe handles broken per linear metre of hardwood cut in support of current operations, but will know nothing of the support for a tool that will need a different maintenance methodology, significantly different support materials such as fuel, different storage, many more parts of much greater variety, and so on.
Before the business operations level can even begin to address their requirements, therefore, business management layer above them must decide how the new capability is to be introduced. Is the chainsaw being procured to fell trees faster, or to cut down the same amount of wood more efficiently (with fewer operators, for example)? In either case, will the current tradesmen be retained and retrained, or will new operators be required? What new logistics support will be required and how will it be acquired? How will the company transport materials, such as fuel, that are not currently supported? How will the new capability be maintained, and by whom? How will the new capability be deployed—across all operators at once, or team by team, or area by area? If wood is to be produced faster, will additional transport vehicles be required to extract the product, and will additional sawmill capacity be required? Ultimately, of course, business management must also consider whether they want to produce more wood at the risk of flooding their own market resulting in a falling price?
Before an acquisition can be considered, therefore, the business management level must draft the initial versions of the operating concept, acquisition concept, deployment concept, support concept, and retirement concept. Those concepts can then be fleshed out by the selected stakeholders from the business operations level before passing on to systems designers to develop the system specification.
Looking at the system development top-down then, the need for the three distinct levels is evident and we can see why the lack of business management attention is the principal reason for project failure.
I know from our experience at ArgonDigital, we have had numerous cases where our clients brought us in to help write these kind of “organizational” requirements or to help make sure that the system requirements addressed the higher-level organizational requirements.
Much of the information in this blog is taken from: Ryan, M., Wheatcraft, L, Dick, J, and Zinni, R, “An Improved Taxonomy for Definitions Associated with a Requirement Expression”, Systems Engineering / Test and Evaluation Conference SETE2014, Adelaide, 28–30 April 2014.
I will be presenting this paper at INCOSE IS 2015 in Seattle, WA in July 2015.
Comments to this blog 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.
