The process of creating software solutions requires getting ideas out of the heads of business stakeholders and into the heads of the people building those solutions. Many methodologies and tools attempt to provide structure for this exercise. However, many fall short. Usually, an IT team will create separate technical specifications, and then try to map them back to the original business requirements. Often, something is lost in the translation from one to the other.

Many people are likely familiar with this joke:

What are people doing that leads to results like this? One of the issues is that requirements often lead to sub-requirements and more specification – at every level, a requirement can lead to more requirements. And, if those aren’t specified, then it’s up to the technical team to fill the gaps, and sometimes they don’t fill them in the way that the business stakeholder envisioned. 

Requirements Document

A typical requirements document may look something like this:

---

1. MUST HAVE
   1. Users must create an account before using the site
   2. Users must log in using an email address and password
2. SHOULD HAVE
   1. Users should create an account with a profile that includes their date of birth
   2. Users should create an account with a profile that includes their location (city/state or ZIP code)
3. NICE TO HAVE
   1. Users may upload a picture or avatar
   2. Users may write a description of themselves

---

Another common format looks like this:

Area	Feature	Priority
Account Creation and Authentication	Users must create an account before using the site	1
Account Creation and Authentication	Users must log in using an email address and password	1
Account Creation and Authentication	Users should create an account with a profile that includes their date of birth	2
Account Creation and Authentication	User should create an account with a profile that includes their location (city/state or ZIP code)	2
Account Creation and Authentication	Users may upload a picture or avatar	3
Account Creation and Authentication	Users may write a description of themselves	3

One of the problems with these formats is that every feature becomes a requirement that needs to have more specification. For example:

• How long can an email address be?
• What characters are allowed in the password, and how long (or short) can it be?
• What is the format of the birthdate?

And so on… the more room there is for interpretation, the more room there is for the members of the team to be out of sync with each other.

What are Mind Maps?

There has been a lot written about mind maps. For the purposes of this article, I’ll use the mind map as a visual way to break down requirements hierarchically, with a variable number of lower nodes. This technique offers several advantages over the linear methods like the examples above:

1. The requirements can often be displayed on a single page view.
2. Any specific requirement can be identified and expanded and drilled down as needed.
3. For visual learners, over time, it is easier to recall the requirements by imagining their location in the mind map.

Using Mind Maps to Create Visual Requirements Documents

Continuing the requirements document example, this could be a representation using a mind map:

You can see many elements of the requirements represented here:

• The “Account” feature is visually separated from the other features. This can help you focus your thinking about the feature area. Also, notice how account creation is separated from authentication, as these will lead to very different kinds of work.
• Requirement priorities are visually tagged at their respective branch levels.
• Requirements are broken down hierarchically. This can help you continue to focus and think about a specific requirement in deeper or broader ways. For example, are there other ways to collect a user’s location? Should we use a service to look up a user’s city and state from the ZIP code? Is there an automated way to figure out the user’s location?

One benefit of using mind maps is that it allows you to get on the same conceptual page with someone else. When sharing the mind map visually, you can ask, “Is this part of X, or is it a separate feature?” For example, a product owner may have a requirement to collect a user’s phone number. And another requirement for multi-factor authentication. While you might think these are two different requirements, as you draw out your mind map, the product owner may point out that collecting a user’s phone number is “part of” the multi-factor authentication requirement, and so you should draw the phone number as a sub-requirement.

Another benefit of using a mind map is that you can continue to drill down on more layers of requirements. For example, how must you validate the fields of data you are collecting? These are details developers need, and if not collected, you run the risk of developers filling the gaps themselves instead of business stakeholder’s vision. See below as this example continues to be expanded.

Note that for “date of birth” we think about what the format of the date collection should be, and then ask, “Can we just use a UI control that forces the user to select a valid date?” The question is right in the context of the requirement, which makes it easy to review.

Mind maps also help drive consistency to the requirement analysis. When you think of requirements for one case, that can trigger you to look at similar scenarios. For example, we recognize that “email address” is a string field that a minimum and maximum length should be validated. Mind maps let you quickly look at the other string fields and add that requirement to those fields as well (e.g., password, description).

As is the nature of this type of documentation, requirements begin to blend into technical specifications. Mind maps let you blur the lines between the two. This allows you to directly verify that the technical specifications line up with the business requirements.

Additionally, good mind map tools allow you to collapse lower levels of the map, so you can cater the presentation to the audience you are speaking with by varying the amount of detail shown.

Mind maps can be a powerful tool in breaking down business requirements hierarchically:

• They allow both the business and technical teams to be on the same page.
• They allow technical people to reflect back to non-technical business stakeholders what their request was, and importantly, potentially identify gaps. This reduces the risk of missed requirements significantly.
• They help the author organize their thoughts – prompting them to think through the details of a project.
• They enable projects to get started more quickly as they are faster to put together and explain.

Working with AIM on Your Organization’s Digital Journey

Our team at AIM Consulting consists of experienced and knowledgeable experts who lead technology engagements across industries with deep admiration for each client’s success. Our consultants have the experience required to manage complex and expansive projects, communicate effectively to align phases and increase team collaboration providing shared understandings at all organization levels.

Want to learn more about how Delivery Leadership experts at AIM Consulting can help optimize your business? Let’s talk!

---