Requirements

In the world of analysis, there are few things more confusing than "requirements." Requirements can mean many different things, from strategic business goals to low-level system functions, which implies that different people perceive requirements differently. This often triggers endless discussions about what requirements are and what they are not.

There are plenty of different requirement definitions, yet in our opinion, the only correct one is the following:

REQUIREMENT

A thing that is needed or wanted.

For those who perform requirements engineering, it is not actually important how a requirement is defined. However, the provided definition nicely demonstrates the challenges related to requirements that analysts must face on a daily basis.

1. Requirements are not Always Feasible

The fact that something is needed or wanted does not imply that it will be realized. Implementing a requirement might be evaluated as not feasible under the given constraints—it could be too expensive, too complicated, or take too much time. Or it could be discovered that the requirement does not support business goals. An experienced analyst must be able to answer these questions and challenge every requirement to prevent implementing something that is not feasible or does not provide the expected value.

2. Requirements are Often Unpolished Ideas

When stakeholders say they want something, it does not always mean they really need it. Unless the team has unlimited time and resources, the benefit of each requirement should be assessed. Similarly, stakeholders tend to present their initial thoughts as something almost ready to be implemented. Many requirements take the form of general ideas or wishes that must be analyzed to confirm all constraints, dependencies, related requirements, etc. An experienced analyst must be able to recognize these ideas and explain to stakeholders that the process will be a bit more complex.

3. Requirements And Designs

Even though it is hard to say what is a requirement and what is a design, it is crucial to understand the difference between requirements that define a concrete solution and requirements that leave the specific solution open. Consider the difference between the following requirements:

• "We need to enable the Customer Management System to provide customer data through an interface."
• "We want you to develop a GetCustomer interface accepting a customer ID as input and returning the name and age as an output."

Both statements actually require the team to develop a new CMS interface. Nevertheless, the contract between the stakeholders and the team is different. In the former case, the team is free to design the interface as they want, whereas the latter states they need to follow the given API format.