Requirements

When analyzing and implementing software solutions, the term requirement is used daily to describe what the software shall do or what attributes it shall have. For example, "System shall list all contacts", "The list of contacts shall be ordered by contact name ascending by default", or "System shall support two-factor authentication". Looking closer at the provided examples reveals an important fact that not all requirements are the same. They could be of different sizes, complexities, or levels of detail, which implies that a different amount of work will be required to implement different requirements. Naturally, developing a contact list that is fetched from the database and displayed using a user interface will take more time than implementing just the default contact sorting. But regardless of the differences, they are still software requirements, which specify what is required from the software. However, as shown in this chapter, the analysis could have two different contexts, and describing the software solution is just one of them. If a company faces a problem, it may not be immediately clear how to solve it. Especially in the case of big enterprises, the solution could consist of many components. These components impact various aspects of the enterprise, and software could be just one part of the overall solution. Therefore limiting the definition of requirement only to "capabilities or attributes of the software" is not accurate. The term is broader.

Business Requirements and Software Requirements

There are types of requirements that will naturally trigger the implementation of software or a software feature; for example, "System shall send an email notification when a new order is created". But not for all requirements is the solution clear straight away, and it is sometimes even not guaranteed that it will include any software at all — "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 a software ("We need a system, and it must have these functions"). The latter, on the other hand, states general business needs that could be solved in various ways, including or not including systems and applications ("We require something which would help us solve a business problem"). What is also very confusing for analysts, is a widely held model claiming that these two types of requirements differ only in their level of detail or abstraction. Wherein business requirements are high-level, frequently vague, and decompose into the 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. Rather, software requirements represent a solution whose goal is 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 the need from the business perspective, without saying how it will be achieved. And similarly, software requirements are not just another, more concrete level of business requirements, they do not make business requirements more precise. They rather describe what the selected solution, which is software, in this case, must be capable of meeting the business requirements. They are derived from the business requirements, not decomposed from them.

Separating "What" and "How"

The reason why analysts must understand the differences between business requirements and software requirements is that it is quite important to clearly separate those two types. The goal is to keep the needs independent of the solution. This way, it is possible to describe what is to be solved without binding it to any particular solution. Only then remains the description of the needs valid even though the underlying solution has changed.
The problem is, many professionals consider this pattern "separating what from how". They reference the business requirements the whats and the solution requirements the hows. It is not that simple, though. The semantics of what and how strongly depends on the point of view, so something meaning what for one person could actually mean how for somebody else and vice versa. For example, does this requirements state what or how?

We need a new portal which will list all our active tenders so the potential suppliers could 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 customers online about our new tenders as soon as we publish them
HOW: We want to inform our customers online about our new tenders through a new portal

WHAT: We need a new portal which will list all our active tenders
HOW: The portal should list our active tenders sorted by name, 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 a first step to understand the purpose of requirements analysis. Each requirement elicited with the stakeholders must be assessed in order to understand its type and the impacts it might have. A low-level functional requirement such as "The default date in the field XXX should be the current date" will probably mean just implementing a minor change, not requiring much work. On the other hand, a requirement which states: "We want our partners to be informed about our new tenders" could lead to a big project developing a new system, involving multiple system integrations and possibly a few process changes. Separating these two views helps understand what is a goal to be met and what is a solution that is supposed to help achieve the goal. Decoupling specification from implementation also improves requirements stability and understandability. The better stability is guaranteed because of the "what" usually changes less often than the "how", so changing the solution specification will not require changing the business requirements. Not mixing up both requirement types also makes specifications easier to understand since software requirements do not intervene in business requirements, so the readers do not have to switch contexts. The separation also enables consulting different types of requirements with different stakeholders.

So if 'what' could be 'how' and 'how' could be 'what', how do we recognize business and solution/software requirements? The requirement represents 'what' unless it describes which enterprise components or their parts should be modified - for example, developing a new system, modifying some business process, or doing an organizational change. Going back to the statement "We need a new portal", this requirement describes how the company is going to solve 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, which is informing the customers (what), which stems from the need to be more competitive (why).

Ask For a Need

Many existing books tend to explain aspects of the software development process using comparison to house construction. In most cases, this does not work, as software development is far more complex, so these comparisons are slightly misleading. But there is an exception. House architects never ask customers, "What are your requirements for the house?" It would just lead to the discovery that the customer wants a red roof, which is irrelevant in the stage when the architect needs to understand the purpose of the house and how it is expected to be used. Instead, good architects ask, "How are you going to use the house?" or "What people are going to live in it?". The same applies to software or in general, any other solution to business needs:

Stakeholder: I need you to create a set of Excel macros for me to help me automate the work with the list of our products.

Such a statement corresponds to the "I want a red roof" requirement. What if the house is going to stand beyond the arctic circle? What if it is to have the roof covered with a crust of ice for most of the year? It is dangerous to ask stakeholders how they want to solve something without understanding what they actually are trying to solve. The analyst should not ask "how", they must ask what and why. Only this way could the analyst be a partner delivering value.

Need: The product portfolio has been growing up very quickly and managing the products manually in the Excel sheet became very inconvenient.
Goal: To be able to manage even the big amount of products effectively.

Once familiar with the motivation behind the requirement, the analyst can challenge the solution required by the stakeholders, demonstrate its weak points, and provide alternative solutions. Depending on more in-depth analysis, the presented goal could be solved by a dedicated product management system, a simple Access database with a couple of forms, or just by a proposed Excel macro.