First Step of Requirement Gathering!

First Step is the last Step; until you take second step.

As a first step we need to identify what is the current process (Draft any associated detailed flow diagrams), and what are we trying to build which is “Future Process”, which is vision/mission of the future product. (Draft any associated detailed flow diagrams, which can help stakeholders to understand the future product) and make sure you have a log which assists the project team for tracking & clarifying open questions raised during the development of BRD. Questions requiring research and their respective answers need to be documented, additionally record the date the question was raised, date it was answered, who raised the question and who answered it.

And here comes the requirement statements:  The starting point of business requirements is the identification of high-level business needs and expectations (high-level business requirement statements that will need to be drilled down into more detail in the requirements detail section). This is accomplished via a Requirement Statements.

When you are making a requirement statements make sure of these items…

  1. What is the Scope of the Project?
  2. Do we have any related Projects? Identify other interdependent projects (dependent on this project, or that this project is dependent upon) and how they are related 
  3. Does any project or Business Processes is getting Impacted? Identify other interdependent projects (dependent on this project, or that this project is dependent upon) and how they are Impacted
  4. Do we have any assumptions, which we may need to consider? Identify what is believed to be true, real, or certain (i.e. policies, mandates, expectations, availability of skills or resources, etc.), that the project is moving forward based upon. If the assumptions turn out to be invalidated, an impact assessment for the project will need to be completed, and any issues must be addressed accordingly.
  5. More importantly, Constraints; Define any restrictions, limitations or conditions that may affect the performance of the project, and any boundaries which the project team will need to operate within (i.e. such as mandates limits on the availability of resources/skills, systems / technology knowledge, vendor performance, etc.)
  6. If you have or come across any Deferred Scope Items; I recommend to describe any specific targeted items/areas (scoping points) of the project’s end product that are in scope, but have been deferred to a subsequent release or future initiative
Share this article

Contact info

About us


Join the network: We are Business Folks, analyzing IT projects.
We use cookies to improve our website. By continuing to use this website, you are giving consent to cookies being used. More details…