Requirements definition done sufficiently

How can I tell if we've got enough requirements defined to be successful on the project?
To test the requirements that have been gathered or defined, here are three key areas: 1) Do the requirements adequately express what needs to be developed to meet the goals of the project? 2) Do the requirements define the deliverable(s) to be generated well enough for the team to go design and implement the solution? 3) Can the requirements be used later to "test" or judge thoroughly that the deliverable is truly done, meaning it meets the goals of the project and works or performs as it's supposed to?

Here are some techniques for ensuring you've gone far enough with requirements definition.

  • Have the team construct a simple model or mockup of the deliverable using the requirements. Are there gaps in their understanding of the deliverable that make it hard to create that model or features/functions of the project's deliverable that are poorly or not defined yet in the requirements?
  • Have the sponsor and other stakeholders review the model/concept and ask for feedback on features, functions, etc. Does the model/concept fill the needs of the market or the customers for this project? Can the team define what is in the scope of the project and more importantly define where the scope boundaries are?
  • Is each requirement unique, or do the requirements you've compiled from users or customers express overlaps and conflicting needs?
  • Can each requirement be traced into the some part of that model or mockup of the deliverable—meaning you can see that each requirement is taken into account in your design concept? If some key requirements are not handled yet, what's the issue? Does the scope need further thought or are some requirements not fully understood?
Here are a few questions to ask the team:
  • Does each requirement have a quality measure that can be used to test whether a given solution meets the requirement?
  • Is the requirements coverage wide enough for everything we need to understand in order to to go design and implement this project's deliverable(s)?
  • Is the specification clear enough (e.g., definition of terms) that there will be no misunderstanding about what needs to be created?
  • Is every requirement in the specification truly relevant to the solution we're supposed to produce, or is there something out of scope? (Too many requirements could take the project off the rails as easily as too little.)
  • Is it clear how each requirement relates to value the project is supposed to provide to its customer?

The last important subject to touch on is the nature of iterative requirements definition. Some projects will need time up front working customer discussions and implementation concepts to help ferret out all the important requirements. Teams may decide to tackle parts of a solution first, working out those requirements, before moving to the next stage. Requirements definition activities may not happen all in one round. However, the requirements definition portion of a project shouldn't take on a life of its own as a never-ending quest for completeness and perfection! Remember the three key items at the beginning of this answer, and continue to ask yourself whether you've fulfilled those goals with the requirements you've defined for this project.

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
Learn more about ProjectConnections, our contributors, and our membership levels and product options.