Requirements engineering (3rd ed.)

We live in a commercial world where much of our work is undertaken through a project -oriented approach.

This has the advantage of determining the cost and time of the project to be undertaken, which in their turn are based on the knowledge of what the project is to deliver.

Computing is no different in this regard, and so in order to organize our activities, we need to know what it is that is to be delivered.

Hence Requirements Engineering, an organized approach to determining what is required in the project/ system that is being undertaken.

There are some problems with the idea of Requirements Engineering, which I have on previous occasions encapsulated in a single sentence called 'The Mock Theorem of Information Systems' which states 'There exists some point in time when everyone involved in the system knows what they want and agrees with everyone else' Clearly nonsense (how would you know what everyone is agreeing to for example?).

But in order to build a system on a project basis, this sentence has to be assumed to be true (either explicitly, or even worse, implicitly).

Then Requirements Engineering can be made to work, and the correct prod- uct/ system delivered by the project.

However, we do not have an established alternative to the project approach, and the business world is used to projects.

So Requirements Engineering is necessary, but it needs tempering to allow for the desired certainty actually being unknown.