Description
The whole area of requirements is one that is fraught with conflicts, misunderstandings and many contradictory views and opinions. It is widely acknowledged that getting the requirements ‘right’ is crucial to the success of any project or to realising any form of successful system, but what exactly is meant by this?
It is clear that a good understanding of requirements is important, so why do so few people actually apply any sort of rigour to their requirements engineering activities?
This section discusses these two issues at a high level by looking at exactly what we mean by ‘requirements’ and ‘requirements engineering’ and then looking at some key concepts that are required to ensure good requirements and rigorous requirements engineering activities.
The need for requirements engineering
To understand the requirements for a system, it is not enough to simply state the needs of a group of users, but it is necessary to engineer the requirements of all relevant stakeholders. ‘Requirements engineering’, therefore, is the discipline that enables this understanding and is important for a number of reasons:
● Systems approach. All systems approaches identify a need to understand the requirements properly. This relates to all types of systems whether they are technical, social, financial etc.
● Quality. There are many definitions of quality, but the two that are considered here are from the International Standards Organisation (ISO) [1]. This first definition, which is arguably the most common definition of quality used in the world, is ‘fitness for purpose’. Fitness for purpose means that the system does what it is supposed to do or, to put it another way, the system satisfies its original requirements. The second definition that is cited here is ‘conformance to requirements’ – no explanation needed.
● Requirements drive the project. Every aspect of the project should be traceable back to the source requirements. The requirements should drive everything that is done in the project, and if they are not, then some serious questions need to be asked.
● Benchmark for acceptance. Acceptance testing – the tests that provide the customer with the confidence that the system is fit for purpose are based solely on requirements. Acceptance tests are not based on the design or the implementation techniques that are applied (unless they are constraints) but are based entirely on the requirements set for the system. Therefore, if the requirements are not fully understood, how on earth can the final system be accepted?
● For increased confidence. One of the least tangible, yet most powerful benefits of applying an effective systems approach is one of confidence. When the requirements of the system are understood, the system can be demonstrated and accepted. When the requirements are understood, they can be agreed by the customer somewhere in the initial, or conceptual, stage of a project. This confidence refers to the confidence of both the customer and the supplier sides of the relationships. In other words, the confidence of all the stakeholders will be increased. Although difficult to measure, confidence is an immensely valuable attribute for any relationship.