Requirements Gathering Tricks

The complete collection of requirements that the project beneficiaries might have for an individual project team are not usually readily apparent at the time the project is being requested, envisioned, budgeted, staffed and initiated. And, yet, this same complete collection of requirements is what the initial estimates, plans, skills, and task plans will be measured against when the project is finally in its completion phase(s).

Experts in the art and science of requirements gathering and analysis have postulated that the most critical point in a project's life is during the early stages of each project when these requirements are being identified, quantified, correlated, and prioritized. Even in the more recent practices of AGILE / SCRUM methods, the component that is being focused on in these AGILE / SCRUM sessions (the 'requirement') must be clearly identified before the development efforts in the SCRUM is begun.

Another consideration that is part of the AGILE / SCRUM process is the identification of portions of the targeted capability or requirement that can be removed from the deliverable because of a lack of clarity and / or understanding between the users requesting these capabilities and the developers who are trying to build it. Comparmentalizing a requirement in a SCRUM, Iterative, or Waterfall development process is extremely important if the project team is to make a decision to eliminate a piece of the proposed solution during the performance of the project (AGILE, Iterative, Waterfall efforts are considered all to be projects).

It is especially important to know the up stream and down stream dependencies of the feature being considered for removal before making a final decision. The extent of the impact of removing a capability can be defined by knowing what is before and after the candidate capability.

... the next edit of this post will begin to expand on the techniques that can be used to improve the likelihood of gathering a complete set of requirements bgbg ..