The aim of this article is to highlight the highly context-dependent nature of requirements, and the precautions which must be taken to avoid falling into the classic traps when producing a specification.
The aim of this article is to highlight the highly context-dependent nature of requirements, and the precautions which must be taken when identifying and managing requirements as part of system engineering.
This article does not set out to paraphrase the countless number of works on requirements engineering, but rather to supplement the techniques which can be found in those works with methods and good practices which can be used to avoid falling into the classic traps when producing a specification , such as:
- making undertakings to the customer in regard to requirements which it will not be possible to test;
- allowing the customer to see in unnecessary (possibly even dangerous) detail the technical constraints imposed on subcontractors;
- not defining sub-contractor’s tasks in sufficient detail precisely in order to avoid allowing the customer to see in unnecessary (possibly even dangerous) detail the technical constraints imposed on subcontractors (previous point);
- omitting to define the task of setting the verification strategy for your system.
Which system? What for?
Which system does this requirement apply to? What is it for? Answering these questions is the key to defining the context of a requirement.
We can begin by illustrating this by with a deliberately schematic summary of chapter 5 of [POHL 2010]:
This underlines that part of requirements engineering is to clearly define the system development context.
There is broad agreement within the systems engineering community that verification (the upward branch of the V-model of the system lifecyle), while fundamental, does not constitute the system itself but rather a separate system (human, technical, procedures, etc.), whose function is to verify that the system provided corresponds with what was requested. To achieve this, as we engineer the system we will inevitably add supplementary requirements for the verification system (covering such things as strategy, resources, etc.):
Furthermore, system engineering increasingly involves sharing out the engineering of various subsystems among subcontractors; requirements engineering also needs to take account of this aspect:
In terms of engineering, the verification system may be considered as a particular case of a subsystem, and as all subsystems may also be considered as entirely separate systems, we arrive at the following diagram, which will frame the thinking set out in this article:
This is why whenever a system analyst is dealing with something which he thinks is a requirement, it is essential that he ask himself this question: “Is this part of the specification of my system? Of my system context? Of one of my subsystems? Of the context of one of my subsystems? Of the verification system context?”
Once an answer has been obtained to this question it is very important to know what this requirement will be relevant to.
In this section we use the possible answers to the preceding questions as the basis for analysing good practice for a system analyst.
Picture a system analyst who is working on a system specification, in response to the needs which his client has formulated in a statement of work, and who wants to add a particular assertion to his specification:
“a minimum throughput of 25 images per second will be offered 7/7”.
If the answer to the question “Is this part of the definition of my system?” is “Yes, on the face of it”, the system analyst must first of all identify his assertion as being a (unique) requirement, and give it a title which should (preferably) also be a unique identifier.
If it is difficult to come up with a title, this indicates that the meaning of the assertion is unclear, and it is strongly recommended to reformulate it.
Next, the system analyst should consider the following question: “Will the person in charge of verifying my system (this is very often the same person who specifies the system) be able to verify this on the system?”
If the answer is yes, it is possible that this assertion is indeed a requirement of your system, but additional items now need to be added to define the needs of the associated verification system, for example “verification must be carried out in operational conditions for at least 1 month before the requirement is considered verified”; this new assertion specifies the verification system context, not the system itself.
If you (or whoever is responsible for system verification) do not have the resources to carry out the proposed verification, the question arises whether the client will have the necessary resources.
If so, it is possible that what you took to be a system requirement is actually a need (and so not your responsibility, as you are defining the scope of the problem which you have to resolve, not your system).
If not, it may be that the subcontractor handling one of the subsystems is in a clear position to verify it. If so, this indicates that what you thought was a requirement of your system is actually a component of the context (a need) for one of your subsystems.
Of course, sometimes when analysing an assertion it is immediately obvious that it does not define the system under consideration, but relates instead to the verification system or one of the subsystems.
Below is a high-level view of the sequence of questions/responses needed to deal correctly with a requirement:
Whether you are dealing with:
- a system requirement which provides a response to a specific client need,
- an element of the verification system context which constitutes one of the constraints for constructing the system of verification procedures and possibly the equipment needed
- an element of a subsystem context which constitutes a detailed request to be passed to a subcontractor
… these are all just requirements, it is just a question of your viewpoint.
A particular request that you might pass to a subcontractor is the product of your work in analysing your client’s need, using your expertise.
Therefore it is very important that you know what role a requirement is to play, as you are drafting it:
A system requirement must:
–> Be the response to a client need. So you must:
- Write in terms that your client can understand
- Establish traceability with your client’s need
- Justify your response (system requirement) to your client, if it is not self-evident
- For functional requirements: allocation to subsystems + strategic elements to derive context elements for allocated subsystems
- For non-functional requirements: definition of lines of analysis which will lead to particular design choices for the subsystems
- Definition of verification strategy elements (allocation of test resources, scheduling the verification phase, etc.)
A subsystem context element (definition of needs on the subsystem) must:
- Serve as the basis for a contractual relationship
A verification system context element must:
- Standardise the use of resources required for verification so as to optimise the cost of verification.
An assertion is only considered as a requirement because of one’s specific viewpoint (a requirement for you may be the output of someone else’s work which itself was done in response to other requirements).
The intention behind the system analysis work which defines a requirement may be very variable and the management processes, even the manner of writing (or describing) them must be tailored accordingly.
If this consideration is overlooked, there is a high risk that requirements management will degenerate into making a random and uncoordinated list which is ill-suited to serve as the basis for serious engineering.
 Among existing works on requirements engineering I would however like to mention one which I feel stands out from the rest for its quality: “Requirements Engineering” by Klaus Pohl, published by Springer – [POHL-2010]. This book is recommended reading.