Craft "High-Quality" Requirements

From the Voices on Project Management Blog
by , , , , , , , , , , , ,
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.

About this Blog

RSS

Recent Posts

Fair's Fair

Give Your Project a Home

A Hollywood-Style Move From PM to Scrum Master

To Have and To Hold

Leading With Integrity

Email Notifications off: Turn on

Categories: Project Planning


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?

Posted by Marian Haus on: April 18, 2012 12:51 PM | Permalink

Comments

Mike Collins
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.

Erich Fox
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



SAP DIRECTOR
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.

Todd/The Project Management Steps
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.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"If nominated I will not run, if elected I will not serve"

- General William T. Sherman

ADVERTISEMENT

Sponsors

>