Ambiguous or unclear requirements lead to confusion and waste and result in failed projects.  Luckily, there are a few simple approaches for identifying and fixing ambiguous requirements.

To discover ambiguity in project requirements, we can use a set of four heuristics.

Search Subjective Terms

One of the easiest ways to identify ambiguous requirements is to search for subjective terms.  Subjective terms are words that are not specific and can mean different things to different people.

Words and phrases such as fast, easy, user friendly, and state of the art are all subjective.  How fast is fast?  What’s easy for one person may be difficult to another.

Start by creating a checklist of subjective terms by brainstorming and then scan your requirements for those terms.  When you find a subjective term, change it to something move specific and testable.

For example, “fast” may be changed to “a response time of 3 seconds or less”.

Memorization Technique

With the memorization technique, you read or otherwise briefly share the requirement with stakeholders and then have them recall the requirement from memory.  Often, stakeholders will leave out or replace words or phrases when they recall the requirement.

Missing or replaced portions of the requirement often indicate ambiguity.  This is because the stakeholder’s mind is working to find meaning in what they heard and they omit or add to the requirement to fill in gaps.

Mary Had a Little Lamb Technique

The written word is a terrible way of conveying information.  People can read the same words with different inflection and interpret the meaning differently.

With the Mary Had a Little Lamb technique, you read the requirement out loud stressing different words or phrases to uncover areas that can be interpreted differently.

For example, saying “MARY had a little lamb” implies that it was Mary’s lamb and not Cathy’s or Ann’s lamb.  “Mary HAD a little lamb” implies that Mary had a lamb in the past, but no longer has one.

Ambiguity Poll Technique

The ambiguity poll technique helps you to identify misunderstandings be having stakeholders size the requirement using a common metric.

Differences in the sizing among stakeholders possible indicates that there is not a shared understanding about the requirement.  This leads to a conversation about why people voted or sized it the way they did to uncover any misunderstandings.

This approach is very similar to story sizing used by many agile teams.  Wide differences in story points frequently means that there are differences in understanding about the user story and more clarification is needed.

Listen to the full episode to find out more ways to reduce the ambiguity in your requirements.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA110.mp3

Pick one of the techniques to reduce ambiguity discussed in this episode and apply it to your requirements.  You can do this on your own or for even more impact, do it together with a co-worker.  That will give both of you practice in applying the technique.

President, Group Atlantic, Inc

Scott is a senior advisor to Fortune 500 CXOs, and program and project managers worldwide on the effectiveness, rewards, and risks of their high-tech programs and policies. Currently advising on agile organizations, high-performance teams, techniques for effective product requirement definition and risk management, as well as adapting modern software development techniques to fit specific business needs.

• LinkedIn

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.      

The post MBA110: Managing Ambiguous Requirements appeared first on Mastering Business Analysis.