Background
Traditionally, Requirements Identification, Analysis, and Management was based on "Shall" statements, that is, "the product (service) shall...". Fundamentally, the "Shall Statements" were contractual obligations to be met by the contractor in creating a new product. Systems Engineers and Requirements Analysts would attempt to identify both the requirements' description and metrics for each (i.e., when the requirement was met) by starting the Requirements Identification and Management effort by "shredding" the contract to identify the requirements within "the shall" statements.
Once the contractually contracted "requirements" were identified, the Systems Engineer/System Architect would decompose those requirements, partially in an effort to:
1) identify any requirements gaps,
2) ensure that all requirements were single requirements and not a group of requirements, and
3) identify evaluation procedures to ensure that the requirements were met.
This last reason was a requirement of any Systems Engineering process because most of the contractual requirements had no method for identifying when they were met; they were statements of the capabilities the customer required. For example, within Information Technology (IT) "the system shall be user friendly" is typical. However, what the customer meant by "user friendly" was left to the imagination of the software developer. This particular requirement has led to many "programmer friendly" systems being initially rolled out, a great many cost overruns to "fix the defects" (defects in the requirements), and a great deal of customer dissatisfaction.
With respect to the first two reasons for decomposition, I have seen both the contracts and the requirements stripped from the contracts of several historic aerospace programs and poor the resulting requirements were. The consequence was that Systems Engineers, from the 1960s to the 1990s, spent a great deal of effort and time to decompose the requirements in an attempt to truly identify the real requirements (those that the customer wants, is willing to pay for, and with a definable and quantifiable measurement of when it is met.
Ralph Young, in his book Effective Requirements Practices from 2001, discussed studies that found that less than 50% of the real requirements for a system were in the contractual agreement. Further there were significant numbers of the known requirements that were either conflicting or simply wrong. Since this has been the case for most efforts most of the time, you can understand why requirements decomposition (definition) became such an important function of the Systems Engineer. The decomposition process included State Diagrams, Functional Flow Diagrams and many other "requirements analysis" techniques that enable the Systems Engineer (Requirements Analyst) to tease out as many "missing" requirements as possible.
____________
The Program Management Issue with Requirements (A Sidebar)
Once completed (though many times before completion) the Program Managers and Finance Engineers put a project plan together based on the Heroic Assumption that all of the customer's requirements are known. That is the foundational assumption of the Waterfall process for System Realization; and is patently false. Consequently, project after program after effort fails to meet the programmatic requirements unless the Program Manager simply declares victory and leaves the mess for the operational Systems Engineers and Designers/Developers to clean up. Generally, they do this through abbreviated validation or no validation at all.
The reason they make the assumption that "all the requirements are known upfront" is that it is the only way they can see to create a project schedule, project plan, and earned value metrics to control the effort. Therefore, they religiously believe that their assumption is true, when time after time its proven false. Einstein's definition of insanity is "perform the same test over and over and expecting different results".
Making the assumption that "not all of the requirements are known upfront" makes life much more difficult for the Program Manager, unless the process and functions is designed around that assumption. While this has been done, I for one have done it, it is heretical to the Program Management catholic doctrine. Until Program Management and Financial Engineering "disciplines" learn to put more emphasis on the Customer's System or Product requirements and less on cost and schedule, and understand that the known requirements are merely an incomplete and partially incorrect set of requirements, development and transformation programs will always miss their cost and schedule marks; in addition to having very dissatisfied customers.
(End of Sidebar)
From the mid-1960s to ~2000, I dealt with issue of requirements identification, trying most of the methods described in Ralph Young's book cited above. The net result was that all requirements identification methods failed for one of four reasons.
Once the contractually contracted "requirements" were identified, the Systems Engineer/System Architect would decompose those requirements, partially in an effort to:
1) identify any requirements gaps,
2) ensure that all requirements were single requirements and not a group of requirements, and
3) identify evaluation procedures to ensure that the requirements were met.
This last reason was a requirement of any Systems Engineering process because most of the contractual requirements had no method for identifying when they were met; they were statements of the capabilities the customer required. For example, within Information Technology (IT) "the system shall be user friendly" is typical. However, what the customer meant by "user friendly" was left to the imagination of the software developer. This particular requirement has led to many "programmer friendly" systems being initially rolled out, a great many cost overruns to "fix the defects" (defects in the requirements), and a great deal of customer dissatisfaction.
With respect to the first two reasons for decomposition, I have seen both the contracts and the requirements stripped from the contracts of several historic aerospace programs and poor the resulting requirements were. The consequence was that Systems Engineers, from the 1960s to the 1990s, spent a great deal of effort and time to decompose the requirements in an attempt to truly identify the real requirements (those that the customer wants, is willing to pay for, and with a definable and quantifiable measurement of when it is met.
Ralph Young, in his book Effective Requirements Practices from 2001, discussed studies that found that less than 50% of the real requirements for a system were in the contractual agreement. Further there were significant numbers of the known requirements that were either conflicting or simply wrong. Since this has been the case for most efforts most of the time, you can understand why requirements decomposition (definition) became such an important function of the Systems Engineer. The decomposition process included State Diagrams, Functional Flow Diagrams and many other "requirements analysis" techniques that enable the Systems Engineer (Requirements Analyst) to tease out as many "missing" requirements as possible.
____________
The Program Management Issue with Requirements (A Sidebar)
Once completed (though many times before completion) the Program Managers and Finance Engineers put a project plan together based on the Heroic Assumption that all of the customer's requirements are known. That is the foundational assumption of the Waterfall process for System Realization; and is patently false. Consequently, project after program after effort fails to meet the programmatic requirements unless the Program Manager simply declares victory and leaves the mess for the operational Systems Engineers and Designers/Developers to clean up. Generally, they do this through abbreviated validation or no validation at all.
The reason they make the assumption that "all the requirements are known upfront" is that it is the only way they can see to create a project schedule, project plan, and earned value metrics to control the effort. Therefore, they religiously believe that their assumption is true, when time after time its proven false. Einstein's definition of insanity is "perform the same test over and over and expecting different results".
Making the assumption that "not all of the requirements are known upfront" makes life much more difficult for the Program Manager, unless the process and functions is designed around that assumption. While this has been done, I for one have done it, it is heretical to the Program Management catholic doctrine. Until Program Management and Financial Engineering "disciplines" learn to put more emphasis on the Customer's System or Product requirements and less on cost and schedule, and understand that the known requirements are merely an incomplete and partially incorrect set of requirements, development and transformation programs will always miss their cost and schedule marks; in addition to having very dissatisfied customers.
(End of Sidebar)
From the mid-1960s to ~2000, I dealt with issue of requirements identification, trying most of the methods described in Ralph Young's book cited above. The net result was that all requirements identification methods failed for one of four reasons.
- The Systems Engineer didn't describe the requirements using the customers language and ideas and the Systems Engineer didn't rephrase or translate them into the language of the developers. This leads to many defects, finger pointing exercises, and customer dissatisfaction.
- The second is described in the sidebar. That is, the waterfall process used in most development and transformation efforts was founded on an assumption that is just plain wrong.
- For the types of efforts I was working on, IT transformation projects, the customer's system requirements were only partially based on the process(es) that they were supposed to support. Most of the time they were short-sightedly based on the function that the particular customer was performing. Consequently, "optimizing the functions, sub-optimized the process".
- All customer system requirements were treated the same. I found this to be incorrect and would lead to many defects.
Types of Requirements: Capabilities, Functional Requirements, and Design Constraints
When I started analyzing the requirements in various requirements documents and systems in the early 1990s, I found that there were two classes of requirements, and then requirements that weren't requirements at all, just wishful thinking. The two classes are those that the system "must perform" (or process functions it must enable and support) and those the system "must meet". An example of a must perform requirement is "The system will show project status using a standard form". The standard form would be considered as a must meet requirement because a form is nothing that a system "must perform", but it is a requirement that the system "must meet". This requirement constrains the design. The designer/developer can't create a new form; he or she must create a system the produces the standard form. Therefore, I define it as a Design Constraint, since it constrains the design. Likewise, a requirement that the system "must perform" shows action. Therefore, I define this type of requirement as a customer system functional requirement, or more simple a Customer System Requirement. Finally, there are these "wishful thinking" statements. Many times, these are, in fact, genuine customer needed capabilities, (unknown requirements). The reason they are not requirements is that they have no metric associated with them to enable the implementer to know when they have been met. Therefore, rather than ignore them, I've put them into a category (or type) I call Capabilities. These are statements the Systems Engineer must investigate to determine if they are requirements or not.
In any software development or transformation effort, frequently, there are more design constraints than customer system requirements because there are so many types of design constraints and the relative number of functions is, normally, limited. Typically, an organization does not radically reorganize or transform all of its processes and supporting systems concurrently; if there is a higher risk method to move to the going out of business curve, other than fraud, I don't know it. Instead, the organization will develop or transform a single business function or service in a single project; though it may have several projects.
On the other hand, all development and transformation efforts of an organization are subject to the policies and standards of the organization, to contractual obligation of the organization, and to external laws and regulations. All of these constrain the design of systems. For example, Section 508 of the US Rehabilitation Act effects the development of all governmental websites by ensuring that the visually and auditorially impaired can use the site. Again, the Clinger-Cohn Act effects both the choice of transformation efforts and the products IT can use within those projects, by not allowing software, which has been sunsetted or is being sunsetted, to be used in the operation of many businesses within the United States. This act mandates that those systems must be updated to a current version of the system. Obviously, these constrain the design of a new or a transforming system or service of an organization, irrespective of the function the system or service of the organization.
The organization has other design constraints, like having the organization's logo on all user interface displays, for example, or producing the same formats for the reports coming out of the new system, as from the prior system. The organization may use Microsoft databases and therefore have expertise supporting them; in which case using Oracle or IBM products would not be feasible--except in very special circumstances (e.g., a contractual obligation). Consequently, these "must meet" requirements are pervasive across all of an organization's development and transformation efforts.
In any software development or transformation effort, frequently, there are more design constraints than customer system requirements because there are so many types of design constraints and the relative number of functions is, normally, limited. Typically, an organization does not radically reorganize or transform all of its processes and supporting systems concurrently; if there is a higher risk method to move to the going out of business curve, other than fraud, I don't know it. Instead, the organization will develop or transform a single business function or service in a single project; though it may have several projects.
On the other hand, all development and transformation efforts of an organization are subject to the policies and standards of the organization, to contractual obligation of the organization, and to external laws and regulations. All of these constrain the design of systems. For example, Section 508 of the US Rehabilitation Act effects the development of all governmental websites by ensuring that the visually and auditorially impaired can use the site. Again, the Clinger-Cohn Act effects both the choice of transformation efforts and the products IT can use within those projects, by not allowing software, which has been sunsetted or is being sunsetted, to be used in the operation of many businesses within the United States. This act mandates that those systems must be updated to a current version of the system. Obviously, these constrain the design of a new or a transforming system or service of an organization, irrespective of the function the system or service of the organization.
The organization has other design constraints, like having the organization's logo on all user interface displays, for example, or producing the same formats for the reports coming out of the new system, as from the prior system. The organization may use Microsoft databases and therefore have expertise supporting them; in which case using Oracle or IBM products would not be feasible--except in very special circumstances (e.g., a contractual obligation). Consequently, these "must meet" requirements are pervasive across all of an organization's development and transformation efforts.
Advantages of Separation
When, in the 1990s, I discovered this, I recommended to my management that we start a repository of design constraints to use on all projects of our aerospace and defense corporate organization and have recommended it many time since. In my presentation I envisioned four benefits:
When, in the 1990s, I discovered this, I recommended to my management that we start a repository of design constraints to use on all projects of our aerospace and defense corporate organization and have recommended it many time since. In my presentation I envisioned four benefits:
- It enables and supports the reuse of Design Constraints and their evaluation methods. This makes evaluating them both consistent and cost efficient.
- It minimizes the risk of leaving a Design Constraint out of the requirements since the Systems Engineer has a long list of these from the repository. This is a much better way than either trusting the Systems Engineer to remember or figure it out, or any private lists of design constraints kept by any single Systems Engineer.
- If the Customer System Requirements are separated from the Design Constraints, then the System Architecture process is more effective and cost efficient because the System Architect does not have to attempt to sort these out and keep them straight during the process. (Note: the Customer System Requirements are the requirements that are decomposed and from which the System Architecture is derived.)
- Finally, if the organization uses an Enterprise Architecture process like I have described in I discussed in my posts A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture and Asset and Enterprise Architecture Repository then, understanding of what Systems will be affected with a change in policies or standards becomes a simple effort.
No comments:
Post a Comment