Voices on Project Management

> Back to Voices Home

Craft "High-Quality" Requirements

| | Comments (4) | TrackBacks (0)
Project requirements derive from concrete business needs or business-use cases and constitute the foundation for the project work. Without requirements, projects cannot exist.

Incomplete and unclear requirements may result in project failure. Moreover a significant part of project rework is attributable to problems with the project requirements.

On the other hand, requirements that are clear, complete and understood by all the parties are of "high quality." They build a solid foundation for the project work.

Collecting high quality requirements can be a challenging endeavor for several reasons:

•    Stakeholders often don't speak the same language (business vs. technical)

•    Stakeholders have different understandings and views of the product

•    Stakeholders have different backgrounds and expertise on the matter

It may not be the project manager's role to collect, qualify and write requirements. But he or she is often the one planning the framework and determining or approving the guidelines by which requirements are elicited, qualified and accepted.

The following guidelines should help in collecting high-quality project requirements:

1. No requirements without a use case
Usually, requirements can be linked to concrete business cases, which are generally task- and user-centric. Use cases help understanding the requirements' context and purpose.

2. Requirements language
Pay attention to the wording. Avoid ambiguous words. Use words and terms consistently.

You might consider using a glossary of terms to ensure common understanding.

Avoid words that have subjective meaning (nice, substantial, safe, simple) and that enforce direction weakly or that undermine commitment (often, always, partially, usually). Use "shall" or "must" instead of "should" or "might."

Remove any room for interpretation. Avoid the usage of "and/or" together or "including but not limited to."

3. Requirements characteristics checklist
Build a checklist of requirements characteristics that are relevant to your project's quality standards. Evaluate each requirement against the checklist.

Here are 10 characteristics that I successfully use to evaluate the quality of requirements:

Atomic: Is this a single requirement or multiple requirements in one?

Complete: Is this comprehensive enough to start working on it?

Traceable: Is this related to a use-case or need?

Logical and Clear: Does it make sense? Does it leave no room for interpretation?

Consistent: Is this consistent with the project objectives and other related requirements?

Measurable: Is this measurable once a solution is delivered?

Compliant: Is this aligned to the current product features, system architecture and legal framework?

Feasible: Is this realistic and doable given the complexity and the project context and constraints?

Necessary: Is this really required given the project objectives and constraints?  Or is it more of a want than a need?

Prioritized: What are its criticality, urgency and priority?

What best practices do you use to ensure that project requirements are of high quality?

 

Bookmark and Share

 

The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

0 TrackBacks

Listed below are links to blogs that reference this entry: Craft "High-Quality" Requirements.

TrackBack URL for this entry: http://blogs.pmi.org/mt-tb.cgi/801

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.

4 Comments

Great article and tips. These will go a long way to ensuring your project is set up for success.

In addition to your tips, I think that clear documentation and constant communication of requirements to all involved in the early phases of a project are critical to ensure a common understanding of requirements.

Also, as you mention, it is critical to analyze your list of requirements as it has often been my experience that the PM is ultimately responsible for vetting through these and determining real requirements vs 'nice to have's'. Great article.

On my projects i expect business requirements to be clear, detailed and defined in such a way that fit gap analysis with each business requirements can be done.

Also SAP business requirements should be traceable all the way into design, build and testing so that these can be tracked.

Thanks for this great summary and terrific reminder Marian. I shared this with my group - with a reminder that even a simple request is a project with requirements.
Best,
Erich
Toronto

A useful method of making requirements "tighter" on both sides is to add a "testing" section to the requirements document detailing how the business user/customer would test the requirement once delivered.

Often this brings up clarifications or even new requirements and forces the customer to think more deeply about what they want.

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll

Categories