Requirements

In the world of analysis, there are only a 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 between people what the requirements are and what they are not.

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

REQUIREMENT

A thing that is needed or wanted.

For those who perform the requirements engineering, it is actually not really important how the requirement is defined. However, the provided definition nicely demonstrates what challenges related to requirements must analysts 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 for the given constraints - it could be too expensive, too complicated, it would take too much time, etc. Or it could be discovered that the requirement would not support business goals. An experienced analyst must be able to answer these questions and challenge every requirement to prevent implementing something which is not feasible or does not have the expected benefit.

2. Requirements And Ideas

Very often, when the 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 put their initial thoughts as something almost ready to be implemented. A lot of requirements have a form of just general ideas or wishes which must be analyzed to confirm all constraints, dependencies, related requirements, etc. An experienced analyst must be able to recognize the ideas and explain to the 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 which defines 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 customer id as input and returning 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 specify the interface as they want, whereas the latter states they need to follow the given format of the API.