Classifying Requirements

In the previous chapter, we introduced two basic requirement types: business requirements and software requirements. We also described why it is important to distinguish between these types, which is mainly to separate business goals from their solutions and to enable presenting different requirements specifications to different stakeholders. Besides this basic division, other layers of requirements could be recognized, which form a whole requirements classification. The most popular classification schemas are presented by BABOK and by Karl Wiegers in his book Software Requirements:

Regardless of the classification, all requirements emerge from some business need, which expresses a high-level problem or opportunity of strategic or tactical importance. Business need defines what the enterprise must solve or what it would like to take advantage of, but it does not state how to achieve it. The more concrete strategy is outlined by transforming the business need to less abstract business goals and objectives, which together form business requirements. According to BABOK, business requirements are defined as "a representation of goals, objectives, and outcomes that describe why a change has been initiated and how success will be assessed". They define what needs to be achieved to meet the business need, and it can apply to the enterprise, a business area, or a specific initiative.

The aim of the analysis is to find a solution to the identified business requirements. However, the business requirements themselves are too general to help the analyst find the solution. Therefore, besides asking what the company as a whole must achieve, the analyst must also find the goals of the individual stakeholders. These are covered by stakeholder/user requirements that represent what particular stakeholders need to achieve to meet the business requirements. The only difference between the stakeholder and user requirements is that KW's user requirements relate solely to software, whereas BABOK's stakeholder requirements could be met by any solution, be it some system or not. Both types should be as solution-independent as possible, but in case of user requirements, they define how users will work with a system, even though it might not be yet clear what solution it will be or how it will be implemented.
Following the example from the picture, there are three possible ways of implementing the stakeholder requirements: via manually sent SMS or email, through a simple website or by building a sophisticated portal. It is then up to further analysis to decide which solution is most suitable for the given situation.

User requirements define what the user wants the system to be capable of and how the users intend to work with it. Stakeholder requirements are more general and determine what different types of stakeholders expect from solution, be it a software or anything else.

Solution requirements "describe the capabilities and qualities of a solution that meets the stakeholder requirements". No matter if the solution is a new system or a new process, it must be implemented, and the goal of the solution requirements is to describe the solution in the level of detail, which enables the implementation. They specify functions that the system must provide as well as non-functional characteristics and constraints which the solution must have, such as security constraints or performance requirements.

Business Requirements

Despite the business requirements are formally defined by BABOK as the business goals, objectives and outcomes, there is still a widely held misconception stating that business requirements are everything important to business stakeholders. This antipattern effectively allows calling each requirement a business requirement and putting them all on one heap, which unfortunately happens. It is also strongly supported by people calling every requirement specification a Business Requirements Document (BRD) and including all requirements in it, irrespective of their types, level of abstraction, or importance. Such a document then usually includes everything to be delivered, and unfortunately, it used to be even justified by BABOK (2.0) itself and was only omitted in its 3.0 release.

It is crucial not to mix strategic business requirements with requirements important just to a given class of stakeholders or which describe a particular solution. Requirements specification must clearly distinguish between requirements describing why we need the solution and those actually describing the solution.

Stakeholder Requirements

After it is clear what are the business goals, but before the concrete solution is selected, there always exists a big group of requirements stating what various people in the organization expect from the solution. These requirements are not of strategic importance, they are not tied to any particular solution, and neither do they represent low-level software requirements. They describe the needs of various stakeholders. While business requirements describe what needs to happen from the business perspective to solve the problem, stakeholder requirements describe what needs to happen from the stakeholders' perspective. For example, the company needs potential suppliers to know about its new tenders as soon as possible, so that the tender could be closed faster. This is what must happen from a business perspective to solve the problem. But stakeholders are those who define what exactly the solution will involve. It must enable suppliers to list active tenders, notify all suppliers about new tender through automatic email, and it must also provide a report showing which supplier has opened particular tenders. These requirements are not business requirements as they are not strategic, but they are crucial to stakeholders so they could achieve the identified business goal. They also are not solution requirements, because they might be implemented in the various solutions, and some of them will not even be implemented using any software.

Stakeholder requirements are commonly referred to as "a bridge between business requirements and the various categories of solution requirements". What is meant by this? If the solution is software, stakeholder requirements present the interaction between the user and the system. They state what the user must be able to do with the system, without specifying its details. Stakeholder requirements are not tight to any particular system, so they do not include any implementation details. They typically describe what the user wants to do and how the system responds, usually in the form of user-system scenarios.

For example, the requirement is to enable users to create tender and notify selected suppliers about it right after it is created. This requirement could be described using the following scenario:

1. User creates a new tender
2. User selects which companies should be notified about the tender
3. System makes the tender accessible on the tenders portal
4. System sends a notification to the selected suppliers
5. Use case ends

The above scenario outlines what the solution must be capable of without specifying a concrete system or any implementation details. The "bridge" means that stakeholder requirements are not just high-level business goals, but at the same time, they do not prescribe how the requirement will be implemented. They specify what users need in a solution-independent way.

Functional Solution Requirements

Functional requirements represent the system's functionality. Unlike stakeholder/user requirements, which provide a narrative of how the system is used, functional requirements represent very concrete system functions that can be implemented by a developer. User requirements pose "use cases," and each use case focuses on a common user goal. However, these goals are too abstract to be implemented without knowing the details. For example, let's take a look at step 2 of the previously mentioned "create tender" requirement:

• User selects which companies should be notified about the tender

Which companies should the user be able to select from? Will they be sorted? Is the auto-complete feature required? User requirements are not implementable and must be completed with solution requirements:

• System shall display a list of companies which are in the same category as the new tender
  • The list shall be sorted by the number of tenders each company has already participated in
• System shall display the number of companies selected

Just from these several examples, it could be seen that not all functional requirements are the same - they vary in their complexity. The functional requirement may represent something as small as the definition of how the item list shall be sorted, but it may also describe a complex workflow inside the system. For this reason, functional requirements often form hierarchies, as shown in the previous example.
Functional requirements can also be different in nature. While some define how the system shall respond to some user interaction or how many times per day shall the report be generated, others represent more technical details such as which functionality shall be exposed to other systems through an automated interface.

Non-functional Solution Requirements

When building a system, the core information is what functions it is going to have. But each system has other attributes besides its behavior, such as how the user interface should look, how the system shall perform, how it shall be reliable, robust, or secure. These are the overall properties of the system and its specific functions. These attributes are called non-functional requirements, technical requirements, quality attributes, constraints, or non-behavioral requirements.

DEFINITION

A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.
(source: Wikipedia)

The Real Purpose of Requirements Classifications

Many teams started to classify requirements, but unfortunately, the only thing they did is they started structuring their requirements specifications according to the classification. They ended up with specifications divided into multiple chapters, each dedicated to a single requirement class. However, the aim of the requirements classification is not to label all requirements and put them in their own chapters. The real goal is to understand the individual layers so that it is clear whether the statement is a business objective or just a design of the winning solution, as different types will imply different impacts. What is more, it is even possible to separate requirements into isolated groups. Since the requirements depend on each other, the relationships between them must be traced, and keeping them separated is not very convenient for readers as they need to put several chapters of specification together to get the whole picture.