Types of Requirements

Definition of a Requirement

A Requirement is a measurable expression of what a customer wants and for which the customer is willing to pay.  Therefore, a requirement has three attributes:

1. It has a description of what the customer wants or desires or some derivation or transformation of what the customer wants or desires.
2. That want or desire is measurable in a way to ensure that the want or desire is fulfilled.
3. The customer is willing to pay for the supplier to fulfill the want or desire.

All types of requirements these attributes.  However, there is another class of documented wants and desires of customers that many customers and Systems Engineers misclassify as requirements.  These wants and desires do not have the second attribute, a metric to determine when the requirement is met.  I call these capabilities and the description, capability statements.  Customers are particularly enamored of the capability statements since, "Customers don't know what they want, but do know what they don't want."  The reason that they are enamored of capability statements is that language is slippery and allows for a great deal of interpretation/interpolation.  This means that if the supplier presents them with a result the supplier feels meets their capability need, the customer can stay NO IT DOESN'T; and the supplier has no recourse but to default on the contract or or ask for "the real requirements" to implement the product against.  This is very expensive for the supplier and very enjoyable for the customer, especially if they really don't what they want (measurably) and want the supplier to pay for the research; which is essentially what the supplier is doing in this mode of operation.  I have been on too many "opportunities" where I have seen this in action, despite my best attempts to stay the effort until at lease some of the "the real" requirements are known.  When the effort has been stayed by the program or project manager and the customer begins to understand the importance of requirements, as opposed to capability statements, then the customer tends to pay much more attention to "getting the requirements document right".

Types of Requirements and Roles

I will define and delineate the types of requirements by the Roles the identifies or defines and documents them.  There are three roles within the major discipline of Systems Engineering that identify or define requirements, as I discussed in my posts The Definition of the Disciplines of Systems Engineering and Enterprise Architecture and System Architecture and a presentation of the same at 2009 SEI SATURN conference.  The roles are: the Systems Engineer, the System Architect, and the Enterprise Architect.

Systems Engineer

The Systems Engineer identifies and manages the Customer's Requirements.  The Systems Engineer never should define the customer's requirements, but work with the customer to identify the requirements.  Once identified, the Systems Engineer must manage the customer's requirements to validate that these requirements are met.  There are two types of Customer Requirements, Programmatic Requirements and Customer System Requirements.

Customer Programmatic Requirements

There are two types of programmatic requirements:

• Cost--What the customer is willing to pay for a product that meets the System Requirements
• Schedule--How long the customer is willing to wait for the product that meets the System Requirements

Program Management considers the programmatic requirements within their exclusive purview.  They are wrong!  To start with, the Systems Engineer must analyze the known requirements to determine whether or not the effort is even feasible within budget and time constraints. 

Sidebar
To often, business development (or marketing), or for internal efforts, "management" will promise more (in very general terms) than any supplier can deliver.  I call this, "Listening with your mouth!"  Good Systems Engineering practice requires ears.  The Systems Engineer must work with the customer to clearly (measurably) identify the customer's real requirements, in part, by listening to the customer and documenting the requirements the customer states.

End of Sidebar

Once the Systems Engineer, together with any Subject Matter Experts (SMEs), have determined that the effort is feasible, the Systems Engineer must use Requirements Analysis (which I will discuss in a future post) to determine any gaps or conflicts among the requirements.  These should be documented, and if possible, discussed with the customer.  Then the Systems Engineer, SMEs, and Contracts expert should put together a proposal, based on the known and inferred requirements, including a notional Work Breakdown Structure (WBS) with a Bases Of Estimate (BOE), and a notional project plan.  If the proposal is accepted, the Systems Engineer/System Architect and SMEs should refine the WBS and Project Plan before turning it over to the Program Manager (unless the Program Manager is also an SME or Systems Engineer, which, in my experience, they ain't).  In this scenario, the people with the knowledge and the skills to execute the plan are the ones that create the plan; not those only interested in managing the programmatic requirements.

Customer System Requirements

Of more interest to the Systems Engineer, because these are the requirements from which the product will be constructed, while meeting the programmatic requirements (which are a form of Design Constraint), are the Customer's System Requirements.  In the US DoD Mil-Spec nomenclature from the 1970s and 1980s, the customer's System Requirements are the A-Spec.  The reason I bring this up is to show that these requirements concepts are not new.  As I describe in an early post, Types of Customer Requirements and the System Architecture Process, there are two types of System Requirements, those that the product must perform and those the product must meet.

Sidebar
The metrics associated with the Customer's System Requirements are the System Validation criteria.  While some Systems Engineers would argue that they can only Verify that the product meets the customer's requirements.  That misses the distinction between verification and validation.  By the best definitions I've seen, verification indicates that the components or functions meet the component specifications or the functional requirements.  Validation means that the product meets the customer's system requirements, that is, it does what the customer requires.  Many times all the parts of a product work as specified by the System Architect, but the System Architect did not specify a product, in total, that would meet the customer's system requirements.  That is the key difference and the rest is semantics.
End of Sidebar

Customer Functional Requirements

The Customer's Functional Requirements are those requirements that the product, system, or service "must perform".  The customer's functional requirements are based on how the customer envisions using the product.  For example, in IT, it would be "one way one type of user would use the application, system, or service".  This is nearly the exact definition of a Use Case (see the Glossary for the exact definition).  I've found that Use Cases are the simplest, clearest way for the Systems Engineer to communicate the customer's functional requirements to the development/transformation team.  Again, a Functional Requirement is always an action.

Design Constraints

Design Constraints are those requirements that the product, system, or service "must meet".  For example, the customer might want a display in the new Service or a report from the new Service to be identical with that of the current application.   Or the customer might want given level of dependability, the term which the Reliability, Maintainability Serviceability organization uses as the umbrella for all the "-ilities" (e.g., reliability, maintainability, serviceability, scalability, recover-ability, response time, up-time, etc.).  These are all attributes of the product, system, service.

There are many types of Design Constraints.   For example, internal and external policies and standards all constrain a design of the product and there can be sever consequences if a supplier ignores one or more of theses Design Constraints, even if the Systems Engineer does not know of them.  The Systems Engineer has to verify that all of these Design Constraint, type requirements, are met before the product is put into operation.

System Architect

The System Architect transforms the customer's System Requirements in the product's Functional Requirements, then orders and structure these Functional Requirements into a System Architecture or Functional Design, allocates tightly coupled groups of these requirements, together with the Design Constraints, to candidate Components Requirements or Specifications, and finally to perform Trade-off Studies to determine the initial Bill Of Materials (BOM).

System Functional Requirements

The System Functional Requirements (or Functional Requirements) are a set of functions the product, system or Service must perform to meet the Customer's System Requirements.  In the US DoD Mil-Spec terms, this would be the B-Spec.  The Functional Requirements are the result of a transformation of the Customer's System Requirements by the System Architect.  This transformation is the result of two fairly complex procedures, Decomposition (a form of Requirements Analysis) and Derivation (which can use a fairly formal process including UML diagrams, but that requires significant creativity if done properly.)

System Component Requirements (or Specifications)

System Component Requirements (or Specifications) are the requirements for the actual components needed to create the product, system, or Service.  In the US DoD Mil-Spec terms, this would be the C-Spec.  Again, the System Architect transforms requirements, this time it is the Functional Requirements into the Component Requirements.  Again the transformation is a result of two fairly complex procedures, the creation of a System Architecture, also called a Functional Design through ordering and structuring the requirements.  Then the System Architect allocates both the grouped System Functional Requirements and the Design Constraints to potential components.  The System Architect can use metrics associated with the System Component Requirements (specifications) within a trade-off study function to determine the actual components that the product will use.

Enterprise Architect
The Enterprise Architect supports the organization's leadership in optimizing their investment decisions, their policies and standards, to enable the organization to achieve its Vision, and Mission, as I've discussed in A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture and Governance, and Policy Management Processes: the Linkage with SOA. Optimizing is not increased cost efficiency of the investment, but the effectiveness of the processes used to achieve the mission or goal, and the cost efficiency of the tooling in supporting the effective processes. This is exceptionally important to any organization, since it can mean the difference between thriving and not surviving.

To adequately perform his or her role, the Enterprise Architect must work with three types of requirements, the Organizational performance requirements, Organizational (business) process requirements, and service component requirements.

Organizational Performance Requirements

There are three layers of performance requirements for an organization they all derive from the organization's Vision Statement.  For example, the Vision Statement for the United States--one of the best I've seen--is its Preamble,

We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.

As you can see, there are a series of statements "establish Justice", "provide for the common defence", and so on, that both provide the Vision and give a broad hint at both a series of Mission Statements and the method for measuring the achievement of the Vision through the various Missions.  These are the Vision Requirements.  These Vision Requirements enable the measurement of the success of the organization's various Missions.

To realize the Vision, organizations create various Missions.  Military organizations are best known for Missions, while many business organizations have a goal with multiple objectives fulfilling the role of Vision and Mission.  To perform a Mission, it has Mission Requirements, that is, needs that must be fulfilled to perform the Mission.  These include requirements for the Strategies, Processes, and enabling and supporting tooling.  The Enterprise Architect can use the metrics from these requirements to determine the success of the Strategies, Processes, and tooling in supporting the Mission, and through the Mission's requirements linkage to the Vision, their success in achieving the organization's Vision.

The final class of objects Strategy Requirements are needs of a strategy (guidance for achieving the Mission), in terms of the processes and tooling to enable and supporting it.  Products to enable and support these are supplied by the Processes and tooling.  Therefore, they are the key "business requirements" imposed on both the processes and tooling.

Organizational (Business) Process Requirements

The Organizational (Business) Process Requirements come from two sources.  The first set is the requirements of the Performance Architecture (Mission and Strategy Requirements) and the second set is derived from other Organizational Process Requirements.  This set of requirements falls into two categories.

Mission Alignment Requirements

Mission Alignment Requirements are needs of the Mission and Strategies that the processes and tooling must perform must perform to achieve the organization's vision.  Additional Mission Alignment requirements may be imposed on one process by another process.  These tie measurably back to the Mission and Strategies.  The Enterprise Architect uses them to determine which processes and tooling to retire, which to transform, update, or upgrade, and what new processes and tooling the organization requires move toward achieving it Mission and Vision.  This is the objective of the Mission Alignment process.

Policy and Standard Requirements
Policy and Standard requirements are needs the processes and tooling must meet to reduce the intra-organizational process friction, thereby making the processes and tooling both more process effective, and also more cost efficient.  The Enterprise Architect uses these requirements to identify candidate policies, standards, and business rules to enact, revise, or delete.  The Enterprise Architect will use this information and knowledge to support the organization's Governance process.

Service Component Requirements
As a result of the Mission Alignment process, the organization's leadership will fund individual development and transformation efforts.  Mission Alignment identifies "customer requirements" from the Enterprise level.  These are "Customer" Functional Requirements and are used by the effort's Systems Engineer.  The products of the Governance and Policy Management process are Design Constraints also used by the effort's Systems Engineer.

So, as you can see, all of these types of requirement form a requirements web or mesh.  And all of them, if use consistently and in concert can substantially boost the velocity of the organization toward its Mission and Vision.