Requirements are at the very heart of business and IT change. A requirement is a feature or characteristic that has been requested by a stakeholder and may form part of a solution. Requirements are elicited so that they may be recorded for future consideration and are then analysed to determine whether or not they should be included within the solution. Some requirements impose constraints upon the solution and need to be analysed to consider the extent to which compliance is necessary or possible.
Ultimately, requirements determine what a solution should provide and how well the solution should perform. There is a wide range of performance aspects including areas such as security, usability, accessibility and scalability. Some requirements are expressed as outline, vague ideas while others are detailed and specific and provide a firm basis for testing the solution. Sometimes it is necessary to delve into the detail of a requirement at an early stage while on other occasions the requirement can evolve over time as the solution emerges.
The term ‘requirement’ is sometimes assumed to be relevant only where a linear software development approach applies but this is not correct. Business change solutions are holistic and have to meet business needs that are expressed as requirements. While these requirements may be fulfilled by software products, this is not necessarily the case and, even where software is at the core of the business changes, there are alternatives to developing software. For example, a packaged solution may be purchased or an outsourced service provider may be contracted to supply the required functionality.
The approach adopted to define requirements varies according to the business and project context, and the standards applied within the organisation. This variability requires business analysts to be knowledgeable and adaptable, possessing skills that enable them to work effectively across different contexts and with a range of stakeholders.
Requirements definition is often viewed as a straightforward activity that merely requires access to business staff who can advise on what a solution should provide. However, this view has been proven to be a root cause of problems with business change design and software development for many years. In practice, requirements definition is a business analysis service that requires knowledge, experience and analytical skill.
Problems with requirements
Studies carried out on IT project failures over the last 30 years tell a familiar story. The problems highlighted include the following:
• A large proportion of errors (over 80 per cent) are introduced at the requirements analysis stage.
• Very few faults (fewer than 10 per cent) are introduced at the development stage; developers are coding things right but too often not coding the right things.
• Most of the project time is allocated to the development and testing phases of the project.
• Less than 12 per cent of the project time is allocated to the requirements analysis phase.
• There is poor alignment of the developed system to business strategy and objectives.
• There is poor requirements management.
The inherent difficulties in understanding and defining requirements has been declared a primary cause of problems with information systems projects. The lack of well-understood and defined requirements is often linked to customer dissatisfaction with delivered systems.
Walia and Carver (2009) identified over 90 causes of requirements errors in a study that reviewed 149 research papers. Key problems with requirements identified during this study include:
• Lack of relevance to the objectives of the project.
• Lack of clarity in the wording, or ambiguity.
• Duplication or conflict between requirements.
• Requirements expressed in such a way that it is difficult to assess whether or not they have been achieved.
• Requirements that assume a technical solution, rather than stating the features to be delivered by the system.
• Uncertainty among business staff about what they need from the new system.
• Business staff failing to identify all requirements.
• Inconsistent levels of detail.
• Business staff and analysts taking certain knowledge for granted and failing to ensure that there is a common understanding.
The conclusion to be drawn is that poor requirements contribute significantly to project problems and failures. This is irrespective of the development and delivery approaches adopted.
Requirements Engineering Framework
The RE framework was developed to help improve the quality of requirements by clarifying the activities to be carried out when defining requirements. In the same way that ‘software engineering’ suggests a structured and scientific approach to the development of software, RE encapsulates a more disciplined approach to establishing requirements. The business analyst needs to elicit, analyse and define requirements carefully in order to provide a firm basis for developing business and software solutions. The RE framework helps business analysts to do this.
The RE framework sets out five core activities, and the key interactions between them, that need to take place if requirements are to be well defined. The term ‘well defined’ does not mean that the requirements need to be specified in exhaustive detail, but it does mean that they should meet certain criteria; primarily, that they are unambiguous, well-structured, correct and relevant.
The scope, depth and timing of the requirements work depends upon the project context, in particular the development and delivery approach adopted. In some circumstances, a detailed, validated and traceable definition of the entire set of requirements is needed before any development work may begin. In other situations, a set of outline requirements may be defined, each of which is decomposed and further elaborated when required. Another possibility is to define requirements in batches, in order to meet the organisation’s business priorities.
The RE framework is set out in:
There are various standards and techniques used to elicit, analyse and define requirements.