Requirements Gathering and Analysis is the critical first step of the classic Waterfall methodology of development. In a nutshell, this is the phase where the customer and stakeholders are consulted to lay out exactly what product or process is required and what that must consist of. Gathering and evaluating requirements properly sets the tone for the whole project – and doing it incorrectly is a sure-fire way to send your project off course.
It can be easy to lump all the requirements steps together when planning a project. But before requirements can by analyzed, they must be gathered. TechRepublic discusses this point in a well written article by Tom Mochal. In it he discusses the pseudo-paradox of the need for an estimate of work before a project begins – but an estimate done without the detailed requirements fully gathered.
Yet we can’t expect to do full detailed requirements gathering and analysis before any estimate is made – because the project will be under, well under development by the time all the requirements are analyzed. The result would be an initial estimate done as much as a third of the way through its development. An ineffective prospect, to say the least.
The traditional approach is to estimate within an acceptable percentage, usually 10%. As Tom points out, however, this comes with the assumption that the team and manager are experienced enough with a given type of project to be able to make such an estimate.
At the conclusion of the analysis phase, the content for three potential documents should be gathered. TechRepublic is on hand again to lay these out in detail. The three documents are the business requirements report, the conceptual systems design plan, and the strategy documents.
Stay tuned for the next few blogs, in which we’ll discuss requirements gathering and analysis further – common problems, tips, as well as some Morton perspective on all of it.