Requirements

When analyzing and implementing software solutions, the term requirement is used daily to describe what the software should do or what attributes it should possess. For example, "The system shall list all contacts," "The list of contacts shall be ordered by contact name in ascending order by default," or "The system shall support two-factor authentication." Looking closer at these examples reveals an important fact: not all requirements are the same. They vary in size, complexity, and level of detail, which implies that different requirements will demand different amounts of work to implement. Naturally, developing a contact list that is fetched from the database and displayed via a user interface will take more time than implementing just the default contact sorting. But regardless of these differences, they are still software requirements that specify what is needed from the software. However, as shown in this chapter, analysis can take place in two different contexts, and describing the software solution is just one of them. When a company faces a problem, the solution may not be immediately clear. Especially in large enterprises, a solution can consist of many components. These components impact various aspects of the organization, and software might be only one part of the overall solution. Therefore, limiting the definition of a requirement strictly to "capabilities or attributes of the software" is inaccurate. The term is much broader.

Business Requirements and Software Requirements

There are types of requirements that will naturally trigger the implementation of software or a specific feature—for example, "The system shall send an email notification when a new order is created." But the solution is not always clear straight away, and it is sometimes not even guaranteed to include software at all—take, for instance, "We need to implement a new regulatory requirement ABC." When talking about requirements, we need to distinguish between software requirements and business requirements. The former specifies requirements for the solution, which is software ("We need a system, and it must have these functions"). The latter, on the other hand, states general business needs that can be addressed in various ways, which may or may not include systems and applications ("We require something to help us solve a business problem").

A common source of confusion for analysts is a widely held model claiming that these two types of requirements differ only in their level of detail or abstraction—where business requirements are high-level, frequently vague, and decompose into detailed software requirements. However, business requirements do not decompose into detailed software requirements, and specifying business requirements in more detail never turns them into software requirements. Instead, software requirements represent a solution designed to satisfy the business requirements:

Business requirements are not abstract, vague statements. It does not matter how concrete or abstract they are, as long as they describe what needs to be done to meet a need from a business perspective, without stating how it will be achieved. Similarly, software requirements are not just another, more concrete level of business requirements, nor do they simply make business requirements more precise. Instead, they describe what the selected solution—which happens to be software in this case—must be capable of to meet the business requirements. They are derived from the business requirements, not decomposed from them.

Separating "What" and "How"

The reason analysts must understand the differences between business requirements and software requirements is that it is critical to separate these two views. The goal is to keep the needs independent of the solution. This way, you can describe what needs to be solved without binding it to a particular solution. Only then does the description of the needs remain valid even if the underlying solution changes.

The problem is that many professionals view this pattern simply as "separating what from how." They label business requirements as the whats and solution requirements as the hows. It is not that simple, though. The semantics of what and how depend heavily on perspective, so what means what to one person might actually mean how to someone else, and vice versa. For example, does the following statement express a what or a how?

We need a new portal that will list all our active tenders so that potential suppliers can see them online as soon as we publish them.

• WHAT: We want to be more competitive.
  HOW: We want to be more competitive by informing suppliers online about our new tenders.
• WHAT: We want to inform our suppliers online about our new tenders as soon as we publish them.
  HOW: We want to inform our suppliers online about our new tenders through a new portal.
• WHAT: We need a new portal that will list all our active tenders.
  HOW: The portal should list our active tenders sorted by name, displaying 20 records per page.
• WHAT: The list of our active tenders should be sorted by name.
  HOW: Sorting is controlled by the sortBy attribute of the getActiveContracts() web service.

And so on...

Understanding that "requirement" is a general, rather ambiguous term is the first step toward grasping the true purpose of requirements analysis. Each requirement elicited from stakeholders must be assessed to understand its type and potential impact. A low-level functional requirement such as "The default date in field XXX should be the current date" will likely involve just a minor change that requires very little work. On the other hand, a requirement stating "We want our partners to be informed about our new tenders" could trigger a major project to develop a new system, involving multiple integrations and several process changes.

Separating these two views helps clarify what goal needs to be met and what solution is supposed to help achieve it. Decoupling the specification from the implementation also improves requirements stability and clarity. Stability is better preserved because the "what" usually changes less frequently than the "how"; thus, modifying the solution specification will not require rewriting the business requirements. Keeping these requirement types separate also makes specifications easier to read since software requirements do not clutter business requirements, allowing readers to stay within a single context. Furthermore, this separation enables analysts to consult different types of requirements with different groups of stakeholders.

So, if "what" can be "how" and "how" can be "what," how do we distinguish between business and solution/software requirements? A requirement represents a "what" unless it describes which enterprise components or parts should be modified—for example, developing a new system, modifying a business process, or making an organizational change. Going back to the statement "We need a new portal," this requirement describes how the company is going to achieve the goal "We want to inform customers about new tenders." Therefore, it represents the solution—the "how." The portal (how) is a solution to the goal of informing customers (what), which stems from the strategic need to be more competitive (why).

Ask For the Need

Many books tend to explain aspects of the software development process by comparing it to house construction. In most cases, this comparison fails because software development is far more complex, making such analogies misleading. But there is one exception. House architects never ask clients, "What are your requirements for the house?" That would only lead to discovering that the client wants a red roof, which is irrelevant at a stage when the architect needs to understand the purpose of the house and how it will be used. Instead, a good architect asks, "How are you going to use the house?" or "Who is going to live in it?" The same principle applies to software, and to any solution for business needs in general:

Targeting raw execution details directly from unverified requests often results in missing the actual business value.

Stakeholder: I need you to create a set of Excel macros to help me automate how we work with our product list.

This statement is the equivalent of the "I want a red roof" requirement. What if the house is going to stand beyond the Arctic Circle? What if the roof will be covered in a thick layer of ice for most of the year? It is dangerous to ask stakeholders how they want to solve a problem without first understanding what they are actually trying to solve. An analyst should not ask "how"; they must ask what and why. Only then can they act as a partner who delivers real value.

• Need: The product portfolio has been expanding rapidly, and managing products manually in an Excel sheet has become highly inefficient.
• Goal: To be able to manage a large volume of products effectively.

Once familiar with the motivation behind the requirement, the analyst can challenge the stakeholder's proposed solution, highlight its weak points, and present better alternatives. Depending on a deeper analysis, the stated goal could be solved by a dedicated product management system, a simple Access database with a few forms, or indeed, the originally requested Excel macro.