The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to firstname.lastname@example.org from the e-mail address which you have registered with.
This article is the second in a series of articles on requirements engineering published by Crescendo Technologies, following "This is not a requirement (of this system)" . The first article encourages the reader to ask the right questions when drawing up a system specification, which is the technical response to a request made by the client:
Here we will focus on a management best practice which is very advantageous when:
These two factors are often present in the military or aero-nautical domains, from where the best practice set out in this article originated. Expressing a request in terms of a mass of requirements is often the result of a client's highly industrial past; they tend to impose a great number of constraints when formulating their needs  .
My approach will not be to address how to manage the relevance of such constraints, either from a substantive or from a formal point of view, which in requirements engineering is treated as part of elicitation/negotiation techniques .
Here we will be concerning ourselves with how to handle a client requirement according to the nature of the verification effort required, through the prism of a technique referred to as "delegation of requirement verification". This technique, if correctly applied, avoids a classic trap in treating client requirements (the context), when defining the system commitment which one is ready to undertake in response to the client's request, by drawing up a system specification. The trap is to systematically try to formulate the commitment in terms of "system requirements" which meet every single "client requirement".
Defining your commitments to meet the client's technical constraints in the same way as the commitments meeting the client's technical requirements risks inflating the effort required for technical verification at system level. Dealing with a client technical constraint by "delegating" its verification allows you to define a management commitment for the system team. This commitment is to inspect that the technical constraint is correctly tested by the sub-contractors responsible for the sub-systems to which verification is delegated.
A constraint is a requirement which is expressed within the scope of the solution. To put it another way, it is a requirement which does not define a need, but rather a way of responding to a need, where the need itself may not be expressed. An example:
"The electrical power source must be able to be provided by two LR6 alkaline batteries"
Apart from the constraint imposed by the client possibly being unjustified (but that's another discussion: see elicitation and negotiation of requirements), this requirement clearly imposes detailed choices within the solution. Let us suppose that we decide to accept this client constraint in its unmodified form: In this case the system engineer will no doubt (it's even strongly recommended) carry out a system impact analysis to feed in to his system specification through "system requirements"-type commitments.
Limiting system requirements to meet ONLY client needs has the following beneficial effects when drawing up system requirements:
A simple (though not perfect) technique for spotting that a client requirement is actually a constraint is to perform an analysis to allocate the client's requirement to the sub-systems at the level immediately below our system. If the requirement can be allocated to several sub-systems, there's a chance that the requirement is not a constraint. But take care not to make this a rigid rule. An example:
"The aircraft must be entirely pink", since this example client requirement can easily be allocated to the sub-systems "fuselage", "wings" and "wheels", yet it is clear that the requirement is truly of the nature of a constraint and it is not relevant to apply a system response; so we will delegate verification of this client constraint to these three sub-systems.
Once a requirement has been clearly established to be a constraint, and even though no attempt will be made to set up corresponding system requirements (see previous section), there is nonetheless no question of not dealing with it in the system engineering approach, and it is essential to demonstrate to your client your commitment with regard to those requirements to which you have not provided a direct response at system level (with system requirements).
The treatment of this constraint consists of:
The transfer is done based on the allocation work carried out on the client's requirements (see section 2 "Distinguishing constraints from other requirements") : we can now transfer the constraint to the allocated sub-system(s).
This involves making the client constraint into a requirement for the allocated sub-system(s), without going through an intermediate system requirement:
There must of course be traceability between the requirement in the statement of work for sub-system X and the client constraint, but its semantics (for example "Delegated from") must be different from that used between system requirements in your response and client needs (for example "Satisfies"). This will lead to better-controlled information system.
It is entirely possible (often even recommended) to reformulate the constraint as formulated by your client before transferring it to your sub-contractor(s). Your client's constraint: "The electrical power source must be able to be provided by two LR6 alkaline batteries" could be reformulated as: "It is essential that LR6 batteries can be used to power the system":
It is important to note that this reformulation is not normally visible to the client (who will be aware of the constraint being delegated to the subsystem and of the means for verification ).
In some cases the constraint may be more substantially reformulated: "It is essential to be able to power the system using LR6, LR3 or LR4 batteries" and in this case further justification must be added which may be found in a requirement in your system specification: "It must be possible to power the system using batteries which are widely available in general retail outlets"
Generally, delegating verification of a client constraint should not remove the need for you to make a system impact analysis which might lead to you produce system requirements and/or modify your system architecture.
In the case of a client constraint, your commitment stems from the fact that:
So you must provide to your client as commitments:
One of your roles in communicating with your client is to assure them that the system which you will deliver matches what you committed to deliver (and to which they agreed). Your technical commitments with regard to the system are defined in your response (system specification) and you also defined a set of verification procedures to verify that your system meets these commitments.
Thanks to the traceability you have set up between the client's requirements and your own system requirements (technical commitments) you will be able to compile a report for your client proving that the system correctly meets these commitments:
However, this traceability does not include the client's constraints. Since you have delegated verification of these constraints to those responsible for the sub-systems (see previous section), you will need to use another traceability plan:
This is why it is important to request your sub-contractors (those responsible for the sub-systems) to provide you with a list of the proofs of verification which they have obtained with the traceability against your requirements (from the sub-system statement of work) so that you can supply the proofs to your client.
Of course delegating verification does not mean transmitting proofs provided by your sub-contractors "as is" to the customer. Depending on the type of the delegation, these proofs must be analyzed, reformatted and/or reformulated.
Delegation of requirement verification is a relatively simple technique to set up in terms of information systems, and can substantially improve the quality of the requirements engineering and system engineering processes:
It is important to note that this article sets out a simplified approach for teaching purposes. In the real world of system engineering this approach needs to be kept in perspective with: