The Community Blog for Business Analysts

a.prvz
a.prvz

Requirements Gathering

Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. This may sound like common sense, but surprisingly it's an area that is often given far too little attention.

Many projects start with the barest headline list of requirements, only to find later the customers' needs have not been properly understood.

One-way to avoid this problem is by producing a statement of requirements. This document is a guide to the main requirements of the project. It provides:

  • A succinct requirement specification for management purposes.
  • A statement of key objectives - a "cardinal points" specification.
  • A description of the environment in which the system will work.
  • Background information and references to other relevant material.
  • Information on major design constraints.

The contents of the statement of requirements should be stable or change relatively slowly.

Once you have created your statement of requirements, ensure the customer and all other stakeholders sign-up to it and understand that this and only this will be delivered.

Finally, ensure you have cross-referenced the requirements in the statement of requirements with those in the project definition report to ensure there is no mismatch.

10 Rules for Successful Requirements Gathering

To be successful at requirements gathering and to give your project an increased likelihood of success follow these rules:

  1. Don't assume you know what the customer wants, ask.
  2. Involve the users from the start.
  3. Define and agree the scope of the project.
  4. Ensure requirements are specific, realistic and measurable.
  5. Gain clarity if there is any doubt.
  6. Create a clear, concise and thorough requirements document and share it with the customer.
  7. Confirm your understanding of the requirements with the customer (play them back).
  8. Avoid talking technology or solutions until the requirements are fully understood.
  9. Get the requirements agreed with the stakeholders before the project starts.
  10. Create a prototype if necessary to confirm or refine the customers' requirements.

Common Mistakes

  • Basing a solution on complex or cutting edge technology and then discovering that it cannot easily be rolled out to the 'real world'.
  • Not prioritising the User Requirements, for example 'must have', 'should have', 'could have' and 'would have,' known as the MoSCoW principle.
  • Not enough consultation with real users and practitioners.
  • Solving the 'problem' before you know what it is.
  • Lacking a clear understanding and making assumptions rather than asking.

Requirements gathering is about creating a clear, concise and agreed set of customer requirements that allow you to provide exactly what they are looking for.

This entry was published on Jun 08, 2011 / a.prvz. Posted in Elicitation (BABOK KA), Requirements Analysis (BABOK KA) , Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  6 members liked this article

Related Articles

COMMENTS

a.prvz posted on Monday, June 13, 2011 12:49 AM
Thanks to modern analyst to give me such a good views
a.prvz
RequirementOne posted on Wednesday, April 11, 2012 12:49 PM
Thanks for a great post on requirements gathering. I generally agree with most of the points in particular the points about involving the users from the start (to establish a sense of ownership) and prioritizing requirements which is essential when you establish large sets of requirements. I wrote this blog on top 10 writing good requirements that might be relevant in this context: http://www.requirementone.com/Project-Management-Platform/Blog/2012/01/15/Top-10-Writing-good-requirements-tips
Thanks again for some great articles!
RequirementOne
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC