When we cast out the requirements gathering net and encourage people to tell
us all their requirements, we take a risk. Along with all the requirements that
are relevant to our context we are likely to pick up impostors. These irrelevant
requirements are often the result of a stakeholder not understanding the goals
of the project. In this case people, especially if they have had bad experiences
with another system, are prone to include requirements "just in case we need
it". Another reason for irrelevancy is personal bias. If a stakeholder is
particularly interested or affected by a subject then he might think of it as a
requirement even if it is irrelevant to this system.
Is every requirement in the
specification relevant to this system?
To test for relevance, check the requirement against the stated goals for the
system. Does this requirement contribute to those goals? If we exclude this
requirement then will it prevent us from meeting those goals? Is the requirement
concerned with subject matter that is within the context of our study? Are there
any other requirements that are dependent on this requirement? Some irrelevant
requirements are not really requirements, instead they are solutions.