Classifying Requirements

In the previous chapter, we introduced two fundamental requirement types: business requirements and software requirements. We also explained why it is important to distinguish between them—primarily to separate business goals from their solutions and to allow different requirement specifications to be presented to different stakeholders. Beyond this basic division, additional layers can be recognized to form a complete requirements classification. The most popular classification schemas are presented by BABOK and by Karl Wiegers in his book Software Requirements:

Regardless of the classification framework, all requirements emerge from a business need, which expresses a high-level problem or opportunity of strategic or tactical importance. A business need defines what the enterprise must solve or capitalize on, but it does not state how to achieve it. A more concrete strategy is outlined by transforming the business need into 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 they can apply to the entire enterprise, a business area, or a specific initiative.

The aim of analysis is to find a solution that satisfies these business requirements. However, business requirements themselves are too general to guide an analyst toward a specific solution. Therefore, in addition to asking what the company as a whole must achieve, the analyst must also identify the goals of individual stakeholders. These are covered by stakeholder/user requirements, which represent what particular stakeholders need to achieve to fulfill the business requirements. The only difference between stakeholder and user requirements is that Wiegers' user requirements relate solely to software, whereas BABOK's stakeholder requirements can be met by any solution, whether it involves a system or not. Both types should remain as solution-independent as possible. In the case of user requirements, they define how users will interact with a system, even if the exact nature of the software or its implementation details are not yet clear.

Following the example in the diagram, there are three possible ways to implement the stakeholder requirements: via manually sent SMS or email notifications, through a simple website, or by building a sophisticated portal. Further analysis will determine which solution is most suitable for the given situation.

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

Solution requirements "describe the capabilities and qualities of a solution that meets the stakeholder requirements." Whether the solution is a new system or a new process, it must be implemented, and the purpose of solution requirements is to describe that solution at a level of detail that makes implementation possible. They specify the functional capabilities the system must provide, as well as the non-functional characteristics and constraints the solution must satisfy, such as security policies or performance targets.

Business Requirements

Despite business requirements being formally defined by BABOK as business goals, objectives, and outcomes, there is still a widespread misconception that business requirements encompass everything important to business stakeholders. This antipattern essentially allows any requirement to be labeled a business requirement and dumped into a single pile, which unfortunately happens all too often. This is reinforced when teams call every specification a Business Requirements Document (BRD) and include all requirements within it, regardless of their type, level of abstraction, or importance. Such a document then typically includes everything to be delivered. Unfortunately, this practice used to be justified by BABOK (2.0) itself and was only corrected in its 3.0 release.

It is crucial not to mix strategic business requirements with requirements that are important only to a specific class of stakeholders or that describe a particular solution. A requirements specification must clearly distinguish between requirements describing why we need a solution and those actually describing the solution.

Stakeholder Requirements

Once business goals are clear, but before a concrete solution is selected, there is always a large 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 they do not represent low-level software requirements. They describe the needs of various stakeholders. While business requirements describe what needs to happen from a business perspective to solve a problem, stakeholder requirements describe what needs to happen from the stakeholders' perspective.

For example, a company needs potential suppliers to know about its new tenders as soon as possible so that the tender process can be closed faster. This is what must happen from a business perspective to solve the problem. But stakeholders are the ones who define what exactly the solution will involve: it must enable suppliers to view active tenders, notify all suppliers about new tenders via automatic emails, and provide a report showing which suppliers have opened specific tenders. These are not business requirements because they are not strategic; however, they are crucial to stakeholders so they can achieve the identified business goal. They are also not solution requirements, because they could be implemented across various types of solutions, and some might not even require software at all.

Stakeholder requirements are commonly referred to as "a bridge between business requirements and the various categories of solution requirements." What does this mean? If the solution is software, stakeholder requirements represent the interaction between the user and the system. They state what the user must be able to do with the system without specifying its technical details. Stakeholder requirements are not bound to a specific system, so they exclude implementation details. Instead, they describe what the user wants to do and how the system responds, typically in the form of user-system scenarios.

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

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

This scenario outlines what the solution must be capable of without specifying a concrete system or any implementation details. The "bridge" means that stakeholder requirements go beyond high-level business goals, yet stop short of prescribing how the requirements will be technically implemented. They specify what users need in a solution-independent way.

Functional Solution Requirements

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

• The 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 an autocomplete feature required? User requirements are not directly implementable and must be supplemented with solution requirements:

• The system shall display a list of companies that belong to the same category as the new tender.
  • The list shall be sorted by the number of tenders each company has already participated in.
• The system shall display the number of companies selected.

As these examples show, not all functional requirements are the same—they vary significantly in complexity. A functional requirement can represent something as small as defining how an item list should be sorted, or it can describe a complex workflow within the system. For this reason, functional requirements often form hierarchies, as shown in the example above.

Functional requirements can also differ in nature. While some define how the system must respond to user interactions or how many times a day a report should be generated, others represent technical details, such as defining which functionality must be exposed to other systems via an automated interface.

Non-functional Solution Requirements

When building a system, the core focus is on what functions it will have. However, every system has key attributes beyond its behavior, such as how the user interface should look, how the system must perform, and how reliable, robust, or secure it needs to be. These are properties of the system as a whole and its specific functions. They are called non-functional requirements, technical requirements, quality attributes, constraints, or non-behavioral requirements.

AS DEFINED BY WIKIPEDIA

A non-functional requirement is a requirement that specifies criteria used to judge the operation of a system, rather than its specific behaviors.

The Real Purpose of Requirements Classifications

Many teams begin to classify requirements, but unfortunately, they only use the framework to structure their requirements specifications. They end up with documents divided into multiple chapters, each dedicated to a single requirement class. However, the aim of requirements classification is not to label requirements and isolate them in their own chapters. The real goal is to understand the individual layers so that it is clear whether a statement represents a business objective or merely the design of a specific solution, as different types carry different impacts.

Furthermore, it is entirely possible to separate requirements into distinct groups. Because requirements depend on each other, the relationships between them must be traced. Keeping them strictly separated in different chapters is inconvenient for readers, who must flip back and forth to piece the whole picture together.