(a slightly revised version was published in April 2008 in the Requirements Network)

1 – Requirements come from users.

–>
It’s unusual that the real “user” (the person who will directly use the future system) may express his own requirements directly, before the software product is implemented and released to him. It is more likely that other stakeholders express requirements. There are many roles that may express requirements for a software product.

The main requirements supplier is the client (the person who pays the development project).
It is the client who decides which other subjects, among the various stakeholders (interested parties, with different points of view, in the outcomes of the project) shall participate to the project to give requirements.

The set of project stakeholders may be very large. It involves, besides the client, every future direct user of the system, the users of other systems that give inputs or receive outputs from the system under consideration, other people who may in various ways get advantages or drawbacks from the existence of the system, or from the project decisions.

The selection, among the stakeholders, of those who will take part in the project may be decisive for the project success. To leave aside a stakeholder may result critical, but every involvement has a cost, that must be valued in terms of risk and opportunity.

Obviously, every stakeholder has her own point of view about requirements and project choices. Different points of view that may conflict. In this case, it is the client’s
responsibility to decide among the possible options, and to tell the developers which requirements to satisfy.

2 – The developers’ task is to receive requirements from “users” and develop a product that satisfies the users.

–>
Under these terms, it seems that developers play a passive role in requirements management. In reality, it is a developers’ task the discovery of requirements, the pull out, the pick up, the elicitation.

It’s common to hear from developers that “the user does not have clear ideas”. But the discovery, the emergence of requirements happen through dialog between developers and stakeholders (with the main role played by the client), in a continuous and progressive process: alternative choices come out, they are evaluated, decisions are taken, the effects
of decisions are verified. Requirements are not already completely defined in the head of the user, as some developers would like.

Software products are the output of abstraction processes, they are the result of a progressive knowledge acquisition. At the start of any project only some preliminary requirements are known. Other requirements will come out little by little, as the solution
takes shape. To pretend the opposite would be similar to pretend that a chess player has in his head, before the match starts, every move that will lead him to win; or that a painter has in her head, before beginning to paint, the exact image of the completed painting.

3 – Requirements are not to be discussed.

–>
On the contrary, we have to analyze them, to discuss them, to negotiate them. It is not granted that the stakeholders have clear ideas at the start of a project, or that they are able to express those ideas in a way that is understandable to the developers. And then there is the frequent, already aforementioned conflict between the different point of views.

On a more general level, there may be substantial differences among what the stakeholders ask at the start of a project, what would really solve their needs and what
could be “technically” implemented, and is a potential opportunity. The clarification is to be reached through dialog among the client, the other stakeholders and the developers, and the exam of possible solutions.

4 – Requirements are all of the same importance.

–>
Statistics by the research company Standish Group say that 45% of a system functionalities is never used, 19% hardly ever.

5 – Every requirement must be detailed at the beginning of the project.

–>
Ideally it would be better, but unfortunately it is possible only for very small projects. And, in a long project, to delve immediately into the maximum detail level on everything could be counterproductive, because it makes more likely future changes to manage. The more time passes between a requirement specification and its fulfillment, the more changes may happen. If, for example, a system will have fifteen functionalities, to specify all fifteen in detail at the beginning of the project, in order to start later to implement them, could be less effective and less efficient than specifying and implementing them one by one, delaying as possible the specification detail for the requirements of the functionalities which will be realized later.

6 – Requirements, once agreed upon, can’t be changed, they must be frozen.

–>
Requirements change is a constant (very small projects may be an exception).

Requirement freezing allows developers to work more smoothly, but goes against stakeholders’ needs. When the “all detailed requirements before, implementation later” approach is chosen, the scope and the time length of the freezing are conspicuous, and
problems arise. If, on the contrary, working cycles are incremental and with a short time length, and the detail of requirements is obtained “just in time”, that is just before their implementation, then requirements freezing is no more a problem.

7 – Requirements management is always the same, in every kind of software project.

–>
Systems are different. There are life critical systems, which in case of failures may lose human lives; systems whose failures may lose money; and systems much less critical.

For life critical systems, it is mandatory that the history and evolution of every single requirement be traced with a meticulous documentation. Ideally, less critical systems have the same need, but often the amount of work necessary to document the requirements evolution in a detailed way may conflict with the budget for the project, and with the delivery time asked for by the client.

8 – If a requirement is not explicit, it does not exist. So, the fact that the requirement is not satisfied is not a valid reason to reject the system.

–>
From a legal point of view, this argument may be (in certain countries, at least) imaginable, but from the point of view of the relationship between client and supplier it is unsound and unreasonable. The software developer must satisfy stakeholders’ needs, working with them and helping them to clarify and to express requirements through the progressive realization and verification of actual solutions.

A variant of this commonplace remark says that “if we have not a requirements specification, we cannot test the system”. Quality management systems (ISO9000 and related standards) make a distinction between “validation” and “verification”. Validation
controls if the product satisfies the intended usage, that is, that the system is good for the client. Verification controls if the product satisfies the specified requirement, that is, that the system was built in a correct way. So, the absence of a requirements specification does not allow a verification of the product, but not its validation.

9 – The signature of the client on the requirements specification guarantees that if the final product meets the specification it will be accepted by the client.

–>
From a legal point of view this may be true. But the client is often reluctant to sign, and with some good reasons. The signature on the requirements specification is sometimes used by software developers as a barrier against the client, as if the clients were moody subjects, changing ideas without reason.

When we follow the approach “all detailed requirements before, implementation later”,
the signature on the requirements specification forces the client to cast every decision in the stone, often a lot of time before those details are useful for the needs of the developers. To ask for a “signature in the dark” means that we don’t realize that requirements evolve in time, even through the actual user usage of prototypes and of initial product versions.

To give an excessive importance to the signature on the requirements specification,
that is to think of that document and of that signature as the only real communication
channel, is usually a symptom of an antagonistic, not collaborative approach in the relationship between client and supplier.