A key technique

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 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 ^{[2] [4]}.

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 ^[3].

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.

Distinguishing constraints from other requirements

What is a constraint ^{[2] [4]}

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.

1. "The system shall have direct, toolless access to the power compartment, on the rear face"
2. "The system shall be capable of running uninterrupted at full power for at least 24 hours"

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.

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

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:

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 ^[5]).

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:

• 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.

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:

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.

Conclusion

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

References

• [1] blogs.crescendo-technologies.com/en/this-is-not-a-requirement-of-the-system
• [2] IEEE Std 1233-1998, IEEE Guide for Developing System Requirements Specifications, 1998.
• [3] IREB Certified Professional for requirement engineering. Syllabus – Foundation Level –
• [4] Guide to the Systems Engineering Body of Knowledge (SEBoK) (http://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK))
• [5] See later