My time at International Council of Systems Engineering (INCOSE) International Workshop (IW) 2015 was well spent. The Requirement Working Group (RWG) was well attended.
We had full agenda. Our focus was to update the INCOSE Guide to Writing Requirements as well as developing as set of recommendations for updating ISO/IEC/IEEE 29148:2011 which contains provisions for the processes and products related to the engineering of requirements for systems and software products and services throughout the life cycle.
The updates included adding information to make the Guide consistent with the updates being made to ISO 15288 and the INCOSE Systems Engineering (SE) Handbook concerning the requirement layers above the system layer. (Updated version of ISO 15288 and the INCOSE Systems Engineering (SE) Handbook are expected later this Spring.)
Figure 1. Transformation of needs into requirements (Ryan, 2013).
As shown in the figure rather than thinking the top layer of SE is the system level, there are non-system layers above the system level. As the diagram shows, above the system layer there is a business operations layer, on top of that a business management layer, on top of that and enterprise layer. Within this structure, there are business needs, stakeholder needs, system needs, etc. Through analysis, these needs are turned into requirements at each layer.
– An entity is a single thing to which a need or requirement refers: an enterprise, business unit, system, system element (which could be a product, process, human, or organization). There are entities at each layer.
– Needs are the result of a formal transformation of one or more concepts for an entity into agreed-to expectation for that entity to perform some function(or possess some quality (within specified constraints).
– A requirement statement is the result of a formal transformation of one or more needs into an agreed-to obligation for an entity to perform some function or possess some quality (within specified constraints).
No matter which layer, requirements for that layer have certain characteristics. There are characteristics that address the transformation process of going from needs to requirements as well as going from one level of requirements to the next. There are also characteristics concerning the “agreement” aspect of requirements as well as characteristics on the sets of requirements.
For each “need” the Requirement Engineer (RE) or Business Analyst (BA) asks: what does the system have to do in order for the need to be realized? The resulting engineering analysis results in one or more requirements having the following characteristics:
– Necessary –defines an essential capability, characteristic, constraint, and/or quality factor. If it is not included in the set of requirements, a deficiency in capability will exist, which cannot be fulfilled by other requirements.
– Appropriate – specific intent and amount of detail is appropriate to the level of the entity to which it refers.
– Singular –states a single capability, characteristic, constraint, or quality factor
– Conforming – conforms to an approved standard template and style for writing requirements.
– Correct – an accurate representation of the entity need
Agreed-to Obligation
A requirement is not valid if it not agreed to by both the customer and provider. An agreement implies a formal contract. If the requirement is to be a part of a fair agreement to meet an obligation, the following characteristics of a requirement can be derived:
– Unambiguous – requirement is stated in such a way so that it can be interpreted in only one way
– Complete – requirement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement.
– Feasible – can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk
– Verifiable – structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirements exists
Formal Transformation
A set of requirements results from the formal transformation of the set of needs for an entity. The resulting set will have the following characteristics:
– Complete – requirement set stands alone such that it sufficiently describes the necessary capabilities, characteristics, constraints, and/or quality factors to meet the entity needs without needing other information
– Consistent – set of requirements contains individual requirements that are unique and do not conflict with other requirements. Uniform terminology is used for the same intent throughout the set of requirements
Agreed-to Obligation
If the set of requirements is to be a result of a fair agreement to meet an obligation, the set will have the following characteristics:
– Comprehensible — the set of requirements must be written such that the reader can understand what is expected of the entity and its relation to the macro system of which it is a part
– Feasible — requirement set can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk
– Able to be validated — It must be able to be proven, with acceptable risk, that when realized, the requirement set results in the achievement of the entity needs
Other changes to the Guide include adding rationale for each characteristic as well as providing guidance in understanding the characteristics. The Guide also contains a set of rules that are linked to the characteristics. Following the rules should lead to well formed requirements that have the above set of characteristics.
Another major update we made to the Guide was to add a list of attributes that can be associated with each requirement to aid in the development of the requirement, aid in tracking verification and validation, aid in the management of the requirement, and aid in understanding the context of the requirement and helping to reuse the requirements.
The INCOSE Guide to Writing Requirements update was approved for release at INCOSE IS 2015.
The Guide was updated at IW2017 and has been released in time for IS2017.
Questions and comments are welcome.
