Requirements Completeness

We want to be sure that the requirements specification contains all the requirements that are known about. While we know that there will be evolutionary changes and additions, we would like to restrict those changes to new requirements, and not have to play "catch-up" with requirements that we should have known about in the first place.

Thus we want to avoid omitting requirements just because we did not think of asking the right questions. If we have set a context for our project, then we can test whether the context is accurate. We can also test whether we have considered all the likely requirements within that context.


The context defines the problem that we are trying to solve. The context includes all the requirements that we must eventually meet: it contains anything that we have to build, or anything we have to change. Naturally if our software is going to change the way people do their jobs, then those jobs must be within the context of study.

The most common defect is to limit the context to the part of the system that will be eventually automated. The result of this restricted view is that nobody correctly understands the organisation's culture and way of working