[This post is also available in French]
This article will focus on a management best practice which is very advantageous when:
- a client request (your system context) is expressed in a bloated way, with a mass of requirements
- The system verification means are expensive
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:
Figure 1: Commitments as response to client requests (the context)
Here we will focus on a management best practice which is very advantageous when:
- a client request (your system context) is expressed in a bloated way, with a mass of requirements
- the system verification means are expensive
These two factors are often present in the military or aeronautical 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 sytematically 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.
2. Distinguishing constraints from other requirements
What is a constraint?
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.
- “The system shall have direct, toolless access to the power compartment, on the rear face“
- “The system shall be capable of running uninterrupted at full power for at least 24 hours“
But these system requirements cannot be considered as meeting the client requirement stated above.
The client requirement “The electrical power source must be able to be provided by two LR6 alkaline batteries” is therefore a constraint.
The recommended best practice, as proposed in this article, is not to attempt to formulate a system requirement in response to a client constraint.
Figure2: System requirements do not respond to client constraints
Limiting system requirements to meet ONLY client needs has the following beneficial effects when drawing up system requirements:
1. There are fewer of them
2. The client finds the system specification more pleasant to read, as they don’t notice paraphrases (or even cut-and-paste copies) of their needs.
a. This also gives the impression that the system response is more coherent and offers significant added value with regard to their request.
3. The system verification strategy is easier to define as it does not need to take account of low-level requirements which one often does not have the means (or only with difficulty) to verify at the system level at which we are working.
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.
3. The technique of delegation
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:
- “transferring” the constraint into a requirement applying to one or more sub-systems
- setting up means to validate the verification strategy which your sub-contractor(s) propose to use
- setting up the means for your client to ensure that the proofs of verification supplied by your sub-contractor(s) is returned to them
3.1. Transferring the constraint
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:
Figure 3: Transferring a constraint to a sub-system by delegation
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“:
Figure 4: Transferring a constraint to a subsystem by delegation, with reformulation
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“
Figure 5: Delegating a constraint with reformulation and system-level justification
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:
- you are implementing means of validating the means of verification which will be implemented for the client constraint
- you will be submitting the proofs of successful verification of your client’s constraint to them.
So you must provide to your client as commitments:
- a system response matrix to show traceability between their needs and your system requirements
- a delegation matrix to show the allocation of their constraints to sub-systems, as well as the means of verification which you have defined for the constraints.
Figure 6: Traceability matrices to be provided to the client
3.2. Supplying proof of verification and traceability
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:
Figure 7: Traceability path for system proofs
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:
Figure 8: Traceability path for sub-contracted proofs
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 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:
- By improving the elicitation/negotiation process, as it enables constraints which are risky in implementation terms, but without too much impact from a functional point of view, to be detected
- Distinguishing which of your client’s requirements are constraints, as opposed to actual user needs, makes writing the system response easier, and therefore makes it clearer, as well as strengthening the feeling of trust in your commitment, as you can more clearly demonstrate that you have the means and skills to verify it.
- As a result, the system verification plans will also be easier to follow, as you will not have to make great leaps between, for example, verifying compliance with an operational performance measure and verifying the manufacturing procedure of an individual component buried deep in your system.
- Moreover, making this clear distinction between verifications which need to be carried out at system level and those which should be carried out at sub-system level substantially avoids duplication of verification tasks, which only ends up increasing the cost to the client at a system level.
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:
- The processes of negotiation with clients and suppliers
- The management of sub-contractor risk
- The management of the interfaces between sub-systems, and system integration techniques
Author: Joseph ARACIC