Pitfalls and Best Practices in Requirements Engineering and Management - Requirements Engineering and Management for Software Development Projects - page 204

14.3.2 Preparation for Elicitation and Gathering
of Requirements
If we wish to capture the requirements comprehensively, preparation is essential.
We need to acquaint ourselves with the domain, prepare formats, templates, ensure
that all concerned personnel would be available and that only the right persons are
being contacted and so on before we embark on requirements elicitation. More
often than not, analysts approach this activity with little or no preparation at all.
This will result in making multiple trips or not capturing the requirements
comprehensively.
The best practice is to prepare well before we begin the activity of requirements
elicitation and gathering.
14.3.3 Misunderstanding About Requirements
In many cases, the requirements are wrongly understood. They are understood to
be only the core functionality requirements stated by the customer or end users.
Ancillary functionality requirements are often missed out or left for the software
designers to provide them. Most of the ancillary functionality requirements do not
come from the end users or the customers. They may have to be generated by the
team or from experts in the field.
The best practice is to take ancillary functionality requirements into consider-
ation and establish them also along with the core functionality requirements.
14.3.4 Vague Requirements
It is easy to miss requirements that are not objective in nature while establishing
the requirements. Requirements like ''ease of use'' or ''aesthetically appealing''
are difficult to interpret or implement. By using documentation guidelines, and
effective peer reviews, we can avoid such vagueness from creeping into our
established requirements. We often see such vague requirements in the established
requirements. This shows lack of diligence on the part of those defining and
reviewing the requirements artifacts.
Best practice is to ensure that no requirement is left vague. This can be achieved
by having the right documentation guidelines, as well as, having an effective peer
review.