- It has a description of what the customer wants or desires or some derivation or transformation of what the customer wants or desires.
- That want or desire is measurable in a way to ensure that the want or desire is fulfilled.
- The customer is willing to pay for the supplier to fulfill the want or desire.
- 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
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.
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
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
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 Functional Requirements
System Component Requirements (or Specifications)
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.
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.
Mission Alignment Requirements
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.