Table of Contents
Requirements are the basis for every project, defining what the stakeholders—users, customers, suppliers, developers, businesses—in a potential new system need from it and also what the system must do in order to satisfy that need. To be well understood by everybody they are generally expressed in natural language and herein lies the challenge: to capture the need or problem completely and unambiguously without resorting to specialist jargon or conventions. Once communicated and agreed, requirements drive the project activity. However, the needs of the stakeholders may be many and varied, and may indeed conflict. These needs may not be clearly defined at the start, may be constrained by factors outside their control or may be influenced by other goals which themselves change in the course of time. Without a relatively stable requirements base, a development project can only flounder. It is like setting off on a sea journey without any idea of the destination and with no navigation chart. Requirements provide both the “navigation chart" and the means of steering towards the selected destination.
Agreed requirements provide the basis for planning the development of a system and accepting it on completion. They are essential when sensible and informed tradeoffs have to be made and they are also vital when, as inevitably happens, changes are called for during the development process. How can the impact of a change be assessed without an adequately detailed model of the prior system? Otherwise, what is there to revert to if the change needs to be unwound? Even as the problem to be solved and potential solutions are defined we must assess the risks of failing to provide a satisfactory solution. Few sponsors or stakeholders will support product or systems development without a convincing risk management strategy. Requirements enable the management of risks from the earliest possible point in development. Risks raised against requirements can be tracked, their impact assessed and the effects of mitigation and fallback plans understood long before substantial development costs have been incurred.
Requirements therefore form the basis for:
project planning;
risk management;
acceptance testing;
tradeoff;
change control.
The most common reasons for project failures are not technical. A report created by the Standish Group based on a survey identified that incomplete requirements and the lack of user involvement are primary reasons for project failures. Other reasons include lack of resources, unrealistic expectations, lack of executive support, changing requirements, lack of planning , etc. More than half of those reasons (even the most influential two) are directly related to requirements.
The problems fall into three main categories:
Requirements—either poorly organized, poorly expressed, weakly related to stakeholders, changing too rapidly or unnecessary; unrealistic expectations.
Management problems of resources—failure to have enough money, and lack of support or failure to impose proper discipline and planning; many of these arise from poor requirements control.
Politics—which contributes to the first two problems.
All these factors can be addressed at fairly low cost.
Since requirements are interconnected with other aspects of systems engineering and project management, it is quite challenging to find a satisfactory scope for a definition of requirements engineering.
First of all, what is a requirement? IEEE Standard for Application and Management of the Systems Engineering Process (IEEE Std 1220-2005) gives the following definition:
Requirement: a statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines).
Let us take a short look on the elements of this definition:
Statement. That a requirement should be a statement is perhaps biased towards textual description, while they can also be captured in tabular form or in diagrammatic form (especially when using such a modeling language like UML), in formal notations, or even in domain-specific notations. The important concept, though, is to have a set of traceable, manageable elements identified as requirements.
Product or process. Complete solutions contain varying mixtures of product (things that are built in response to requirements) and process (procedures for using the things that are built). Requirements may therefore define process as well as product. In addition to this, there may be requirements that constrain the way how the product should be developed, usually for quality control purposes.
Operational, functional, or design characteristic or constraint. There are many different kinds of requirement, giving rise to different kinds of language, analysis, modelling, process and solution. Note that this definition has carefully avoided the term “non-functional", because there is a debate about what this actually means. Design characteristics cover performance, usability, safety, maintainability and a host of other qualities.
Unambiguous. A statement of requirement has desirable qualities that will be addressed in detail later. In brief, a requirement should lend itself to a clear, single understanding, common to all parties involved.
Testable or measurable. Requirements are used to test that the design or solution is acceptable. For this to be possible, the requirement should be quantified, thus providing a means of “measuring" the solution against it.
Necessary for product or process acceptability. Requirements play a multi-dimensional role: on one hand, they define what should be designed and developed, and, on the other hand, they also define how the solution should be tested and accepted. So they have an influence in the earliest stages of the development process as well as in the latest stages during acceptance.
By consumers or internal quality assurance guidelines. Requirements come from many sources, including but not limited to customers, regulatory bodies, users and internal quality procedures.
Some other synonyms for requirements are: aims, aspiratins, capabilities, criteria, constraints, directives, doctrines, duties, expectations, features, functions, goals, missions, needs, obligations, objectives, orders, regulations, rules, etc.
The term “stakeholder" has already been used without giving a definition:
Stakeholder: An individual, group of people, organisation or other entity that has a direct or indirect interest (or stake) in a system.
A stakeholder’s interest in a system may arise from using the system, benefiting from the system (in terms of revenue or other advantage), being disadvantaged by the system (in terms, for instance, of cost or potential harm), being responsible for the system, or otherwise being affected by it. Stakeholders are legitimate sources of requirements.
According to [HULL2010], requirements engineering is the subset of systems engineering concerned with discovering, developing, tracing, analyzing, qualifying, communicating and managing requirements that define the system at successive levels of abstraction.
This definition lists carefully selected key activities that are considered proper to requirements engineering. There are some activities closely related to requirements that are considered to be part of some other discipline. An example of this is system testing or verification; while requirements should have the qualities needed to ensure that the solution can be verified, the verification activity itself is another discipline. It also references the concept of requirements existing at various levels of development. Here are some notes on the definition:
Discovering. This covers a number of terms often used, such as requirements elicitation and capture.
Tracing. Tracing of requirements to other artifacts, including requirements at other layers, provides a means of validating requirements against real-world needs, of capturing rationale for the design, and of verifying the design against requirements.
Qualifying. This refers to all kinds of testing activity, covering testing of the design and solution, including unit, component, integration, system, acceptance testing. There is considerable disagreement over the meaning of the terms “verification" and “validation". The term “qualifying" is preferred, because it is about ensuring that the solution has the required “qualities." In so much as the terms are used in this book, to validate requirements is to check a formal expression of requirements against informal needs as understood in the minds of stakeholders, and to verify requirements is to check their internal consistency within layers and between layers of abstraction.
Communicating. Requirements are the means of communication through which customers, suppliers, developers, users and regulators can agree on what is to be achieved.
Levels of abstraction. This is about the practice of organizing requirements into layers and tracing the satisfaction relationship between those layers. The requirements of the top layer define the system in terms of the problems to be solved as agreed by the stakeholders and validated against their real needs; requirements at subsequent layers define the whole or part of the system in terms of an implementable solution as verified against the requirements at the layer above; requirements at every layer provide a precise means of qualifying the solution. Some people refer to the relationship between requirements induced by recording satisfaction between layers as a requirements hierarchy, but in reality the many-to-many relationship forms a graph or heterarchy.
According to [SOMMERVILLE2010], requirements can be classified based on various viewpoints. A popular way of classifying requirements split them based on the level which is bound to how they communicate information about the system to different types of users. Different types of requirements are defined for different audiences. We can distinguish between these levels by using the term ‘user requirements’ to mean the high-level abstract requirements and ‘system requirements’ to mean the detailed description of what the system should do. User requirements and system requirements may be defined as follows:
User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.
System requirements are more detailed descriptions of the software system’s functions, services, and operational constraints. The system requirements document (sometimes called a functional specification) should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.
Requirements should be written at different levels of detail because different readers use them in different ways. Figure Readers of different types of requirements specification [SOMMERVILLE2010] shows possible readers of the user and system requirements. The readers of the user requirements are not usually concerned with how the system will be implemented and may be managers who are not interested in the detailed facilities of the system. The readers of the system requirements need to know more precisely what the system will do because they are concerned with how it will support the business processes or because they are involved in the system implementation.
![Readers of different types of requirements specification [SOMMERVILLE2010]](images/requirementsengineering/readersofspec.png)
Software system requirements are often classified as functional requirements or nonfunctional requirements:
Functional requirements are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do.
Non-functional requirements are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Non-functional requirements often apply to the system as a whole, rather than individual system features or services.
However, the distinction between different types of requirements is not so clear as these simple definitions suggest. A user requirement concerned with security, such as a statement limiting access to authorized users, may appear to be a nonfunctional requirement. However, when developed in more detail, this requirement may generate other requirements that are clearly functional, such as the need to include user authentication facilities in the system.
This shows that requirements are not independent and that one requirement often generates or constrains other requirements. The system requirements therefore do not just specify the services or the features of the system that are required; they also specify the necessary functionality to ensure that these services/features are delivered properly.
The functional requirements for a system describe what the system should do. These requirements highly depend on the type of software being developed, the expected users, and the approach that is applied by the organization responsible for writing requirements together. When expressed as user requirements, functional requirements are usually described in an abstract way that can be understood by system users. However, more specific functional system requirements describe the system functions, its inputs and outputs, exceptions, etc., in detail.
Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services delivered by the system to its users. They may relate to emergent system properties such as reliability, response time, and store occupancy. Alternatively, they may define constraints on the system implementation such as the capabilities of I/O devices or the data representations used in interfaces with other systems.
Non-functional requirements (or, design characteristics), such as performance, security, or availability, usually specify or constrain characteristics of the system as a whole. Non-functional requirements are often more critical than individual functional requirements. System users can usually find some workarounds for a system function that does not really meet their expectations. However, failing to meet a non-functional requirement can mean that the whole system is unusable. For example, if an aircraft system does not meet its reliability requirements, it will not be certified as safe for operation; if an embedded control system fails to meet its performance requirements, the control functions will not operate correctly.
Although it is often possible to identify which system components implement specific functional requirements (e.g., there may be formatting components that implement reporting requirements), it is often more difficult to relate components to non-functional requirements. The implementation of these requirements may be diffused throughout the system. There are two reasons for this:
Non-functional requirements may affect the overall architecture of a system rather than the individual components. For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components.
A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define new system services that are required. In addition, it may also generate requirements that restrict existing requirements.
Non-functional requirements arise through user needs, because of budget constraints, organizational policies, the need for interoperability with other software or hardware systems, or external factors such as safety regulations or privacy legislation. Figure Types of non-functional requirements [SOMMERVILLE2010] shows a classification of non-functional requirements. You can see from this diagram that the non-functional requirements may come from required characteristics of the software (product requirements), the organization developing the software (organizational requirements), or from external sources:
![Types of non-functional requirements [SOMMERVILLE2010]](images/requirementsengineering/typesofnonfuncreqs.png)
Product requirements. These requirements specify or constrain the behavior of the software. Examples include performance requirements on how fast the system must execute and how much memory it requires, reliability requirements that set out the acceptable failure rate, security requirements, and usability requirements.
Organizational requirements. These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s organization. Examples include operational process requirements that define how the system will be used, development process requirements that specify the programming language, the development environment or process standards to be used, and environmental requirements that specify the operating environment of the system.
External requirements. This broad heading covers all requirements that are derived from factors external to the system and its development process. These may include regulatory requirements that set out what must be done for the system to be approved for use by a regulator, such as a central bank; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements that ensure that the system will be acceptable to its users and the general public.