Dealing with ambiguous requirements

by dani.kahilin Mastering requirementson Posted on

Introduction 

One of the main challenges we encounter during Dynamics 365 implementations is ambiguous requirements. Often these come down to a communication issue.

Ambiguity in requirements is common because people use words (and diagrams at best) to describe intangible wishes and desires. Those people have a specific context in their mind, which is driven by past experiences, current work situation or even personal preferences or aspirations.

Getting a shared understanding of what we are building in Dynamics 365 is critical for the success of your project. Well-defined and understood requirements will just make your life easier so take the time and effort to tackle them as soon as possible.

What are ambiguous requirements

A requirement can be ambiguous in two ways:

  1. I can personally interpret the requirement in different ways: Which can lead to significant differences about how I will design the solution. In Dynamics 365 (and more recently the Microsoft Business Application ecosystem) we can design solutions in many ways using a variety of tools. Understanding the requirement is critical so that we can propose a solution that brings the highest business value to our Users. I don’t want to find out after I’ve built the solution that my ‘robust’ is worlds apart from my client’s ‘robust’. 
  2. As a team, we can interpret the requirement differently between one another: I might be on the same page as my client after some in depth discussion, but that doesn’t mean the same goes for the team. Again, it is critical that between us, we have a shared understanding, otherwise the Functional, the Technical and the Architect will go on different paths which will lead to rework or even failure.

Real life exemple:

We were recently elaborating on a requirement for one of my clients. The requirement was “The system must provide the ability to create appointments and appointment invitations must be sent to clients”.

We assumed at the start of the project that Dynamics 365 would be able to meet this requirement by leveraging the standard “Server-Side synchronisation” to send outlook meeting request to participants. Ex: When a user creates an Appointment in Dynamics 365, this appointment gets synched to the organizer Outlook Calendar and get sent to each attendee of the appointment.

However, during a clarification workshop, we discovered that the requirement is actually to send the meeting invites by text message. And that we should never send an outlook meeting request to clients. 

Why it’s important?

By building items that are related to an ambiguous requirement, we run the risk of delivering a solution that end users will not use. There is nothing worse than spending time and money on building something great, to realize that it is useless to your users. 
Ambiguous requirements will only lead to frustration and wasted effort. The feature you build will simply end up by not being used.
Save your client (and yourself) time and energy and make sure the requirement is well understood before you start building your solution. If you use Agile and have your requirements in User Stories, make sure those have enough details in the acceptance criteria so that ambiguity is reduced to the minimum.

Techniques to deal with ambiguous requirements

  1. Use examples: For each requirement that is not clear to you, ask users to walk you through a real example. While doing so, add more details to your requirement. If you use User Stories, examples will help you confirm or write down the Acceptance Criteria.
  2. Replace or remove ambiguous words: Ask yourself the question “How can I test that requirement?”. If your requirement contains words like “Easy to use”, “Robust”, “Faster”, “Many”, etc. how are you supposed to test and mark it as passed or failed? A classic example of an ambiguous requirement is “The system must have a USER-FRIENDLY user interface”. What is “USER-FRIENDLY” for John is not the same for Mary. 
  3. Use visual tools: Elicit requirements using appropriate diagrams, proof of concepts or demo. You are probably familiar with the saying “A picture is worth a thousand of words”. Some of the diagram I use can be found in this related article: Model your Dynamics 365 Solution – Overview (Part 1) 
  4. Compare options: Dynamics 365 (and the Microsoft Business Applications ecosystem) offers a multitude of solutions to meet one single requirement. If there is ambiguity in your requirement, showcase some options to your client to help them clarify their thoughts. 
  5. Ask WHY it’s important: I recommend asking WHY whether the requirement is ambiguous or not. The WHY will give you more context and meaning as to why this requirement is so important to your users. I recently listened to a podcast explaining how our brain is constantly looking for meaning subconsciously. The speaker was explaining that if we don’t fully understand the meaning of a requirement, our brain will make something up. Which can be completely the opposite of what our user had in mind in the first place.  
  6. Storytime Workshops: Elaborate and refine User Stories further during storytime workshops. Use a combination of the above techniques to make those sessions as productive as possible.

“During project and release planning we build user story maps, and then we elaborate and refine the stories further during storytime workshops. But the aim isn’t to write a specification on the back of the card. It’s just enough detail to estimate complexity, uncover dependencies and start development.” – Neil Benson

Related articles:

Real-life example:

I was recently implementing a requirement about storing documents in Dynamics 365. As part of the requirement definition, the following was stated:
  • Documents must be able to be attached to the client profile.
  • A User must be able to scan and upload a document to the client profile.
  • Documents must be organized so that we can quickly find and group documents of the same nature. 
With Microsoft Business Applications, you can meet the above requirements using a variety of solutions:
  • Dynamics 365 notes and attachments
  • Native integration between Dynamics 365 and SharePoint
  • Azure blob storage App, where documents stored in Dynamics 365 are automatically stored in Azure Blog Storage.
Comparing those implementation options helped us identify additional acceptance criteria. Ex: Should the document be editable online? Can everyone in the organization see that document? A comparison will also provide you with positives and negatives for each solution. 

Summary

Ambiguous requirements can create massive issues for you and your team. Beware of vague words, unquantifiable amounts and phrases that are open to interpretation. A good way to help your users define exact requirements is by using examples and visualization. Understanding the ‘why’ behind a requirement will not only help your users be more specific but can help you challenge the way your users are working. However, more about challenging requirements in another article.