Posted by tac_admin, October 9, 2012

Apply These Practices to Promote Excellent Requirements

  • Clearly understand the vision for the end product
  • The project team as a whole should have a shared understanding of the project scope
  • Involve stakeholders throughout the requirements process
  • Represent and discover requirements using multiple models – use cases, process flow diagrams, activity diagrams, etc.
  • Document complete requirements clearly and consistently
  • Continually validate the requirements are the correct ones to focus on (this can change as you progress through the requirements process)
  • Verify the quality of the requirements early and frequently
  • Prioritize the requirements (must have, nice to have, optional)
  • Remove unnecessary requirements (make sure you don’t “delete” them, you may find that you later need a requirement that was removed earlier)

8 responses to “Apply These Practices to Promote Excellent Requirements”

  1. Chika says:

    Hi Teresa,
    Great points. The last point seems contradictory. It says remove unnecessary requirements, yet you say don’t delete them. Can you clarify this please?


    • Teresa Bennett says:

      Hi Chika – I’ll be glad to explain. As an example, if your requirements are in a Word document, I would suggest using the strike through feature in word. You are showing it is no longer a valid requirement, but you still have record of it. If you are using a spreadsheet format for requirements, create a tab in the spreadsheet labeled Removed Requirements and move them to that tab. The point is, whatever format you are using, make sure you keep a copy of removed requirements so that you can refer back to them if the subject comes up again.

  2. Dawn says:

    That’s a good practice that I use a lot – so often you come back to something and ask yourself “why did we decide not to do that” – so I also include (hidden) comments explaining why we took things out

  3. […] keeping an open mind is critical to eliciting requirements  that are clear and […]

  4. […] helps to know which requirements  are most important vs. least important when the project team is determining what could be held […]

  5. […] part of eliciting requirements, the Business Analyst is responsible for posing clear, concise questions and listening for a […]

  6. […] present and maintain requirements, think of them as belonging to categories. Each category of requirement is built on the previous […]

  7. […] Business requirements […]

Leave a Reply

Your email address will not be published. Required fields are marked *

Get in touch today

Speak directly with The Analyst Coach
and get pointed in the right direction.

Preferred Contact EmailPhone

Subscribe to receive our free white paper on how weak requirements effect strong companies


Sign up to get your FREE Business Analyst Survival Guide

Don't worry, we hate spam too. We will never share your information to third parties.