MBA160: The Art of Better Business Requirements

Alyce was interviewed by Podcast Host – Dave Saboe, for his website “Mastering Business Analysis” based on her article – “Perfecting The Art Of Better Business Requirements“.  


A tactic that organizations often use is to assign a subject matter expert (SME) to elicit requirements for a project.  This approach makes sense as a SME will understand the systems and processes impacted by the project and will likely discover and refine the requirements faster.

But what is this conventional wisdom is wrong?  What if the best person to elicit requirements is someone who knows nothing about the current state or the processes and products?

The reality is that experts often make assumptions and fail to ask crucial questions.  They enter a situation with an expert’s mind; a scenario in which there are few options for a solution.  Instead, we need to have a beginner’s mind.  With a beginner’s mind, the options are unbound by preconceived notions.  We are free to ask insightful questions and imagine new possibilities.

Listen to the full episode to find out how to approach situations with a beginner’s mind and fight some of the assumptions that lead to gaps in requirements.

When it comes to a project, regardless of framework, often the key is not just understanding what the customer wants but understanding what they really need.  This comes down to either gathering requirements in a traditional framework or filling the backlog in agile.  Regardless, a clear understanding is needed to ensure that what is delivered, is not just what they wanted, but also filled the need.  Often the debate starts as to who is the best person to gather the requirements.  Is the person who is the subject matter expert?  Well, I would challenge you to consider the possibilities (yeah, I say that a lot).

Over the years I have had the pleasure of working with some amazing business analysts, developers, engineers, and infrastructure folks.  As with every project there are successes and failures.  Below are two examples of what these looked like, and after the analysis is the cause of the success or failure.

Story 1:  Implementation of a new software as a replacement for an existing system.

In this case, I picked up the project when it was already underway.  The project was running in iterations and the person responsible for gathering the requirements was a business analyst who was the subject matter expert.  When I started digging into the project and reviewing the requirements, I saw a lot of gaps and assumptions being made by the business analyst.  In talking with this person she explained that “well she just knew”…really?  This project had been having issues with what it was delivering so at that time I asked for a business analyst that was not familiar with the product.  Guess what?  This business analyst started asking all the questions and was not making assumptions because she honestly did not know the answer.  With a new set of requirements, and a new business analyst in place, all future releases were successful in delivering not only what they wanted, but what they needed.

Story 2:  Upgrade of system already in production. 

In this case, again I picked up the project when it was already underway.  There were several enhancements that were being requested and the development team was working directly with the business.  Luckily, one of the developers was new to this product so he was asking all the appropriate questions and every enhancement implementation met the wants and needs of the customer.

One of the biggest challenges I continually see with subject matter experts, is that they make assumptions that others know what they are talking about; they forget to add in requirements because it is simply second nature to them.  They also often do not ask all the questions that someone without that expertise would ask.  If you are a subject matter expert, go back to the root of what a requirement is.  A requirement is not an assumption; a requirement is not just ‘known’ by others.  There are also many types of requirements that to this day I continue to see left out.

The types of requirements that everyone should consider include functional and non-functional requirements.  Sometimes the business analyst is not the best person to gather the non-functional and system requirements but should have someone with them such as an engineer or architect.  There are also specific questions that go along with these types of requirements when you begin to think about business continuity, backup and restore needs, service level agreements, response times, allowable outage periods, and other areas that a business analyst who is used to the functional or end-user requirements may not even consider.

A lot of people may see other areas of the project, regardless of framework, as the most important.  In my mind, none of that can be successful without a true understanding of requirements.  In today’s agile world, often the requirements that I see skipped over are the non-functional and system requirements.  No thought seems to be given as to asking the questions to understanding storage needed or response times.  If an issue comes up they throw it into the backlog and ‘fix it later’.  This may only be the few organizations that I have worked with in the past, but I also hear the same story from peers working in other organizations.

So how do you fix this large gap?  I would strongly suggest having someone who is not a subject matter expert involved if that is possible.  If that is not possible, make sure whoever is gathering this information, that they do not make assumptions about anything.  In the past the requirement for years may have been that it allowed for an outage of 4 hours, but what if that changes and that question is not asked?  An organization can quickly find themselves with an outage that is now greatly impacting their business, or their clients’ business.  Also, do not assume the want is the same as the need.  I may ‘want’ a mansion, but my need is to just have a roof over my head.  Be careful on inserting what you believe are the requirements of the customer.  If you build me that mansion I am going to laugh, give it back and say I can’t afford to support that mansion.


Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.

Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE
We hope you will consider joining our Facebook Community as well.  Click on the image to your left to visit and join, or you can CLICK HERE




Reading this article qualifies you to submit a request for PDU’s from PMI.

This Article qualifies as follows:



For more information on registering your PDU’s with PMI – CLICK HERE


At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!

If you believe in what we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.

This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE


You may republish this article in whole or in part with attribution to the author and a direct link back to the full article on this site. Attributions MUST include a hyperlink to the original article, as well as a "Canonical Link" reference embedded in the <head> section of the page.
#pmfortoday / #projectmanagement / #pdu / #pmi / #pmo / #pmbok / #pmblog / #pmoblog / #pmp / #pmi-acp / #pgmp


Alyce Reopelle

Alyce Reopelle

Contributing Author

Over 20 years project management experience with a passion for helping organizations grow their PMO, their project managers, and their teams.  My passion has taken me to the pursuit of a Doctor of Education, as I enjoy seeing the proverbial light bulb come on.  I am a believer in continuous growth and improvement, and believe that an organizations culture and environment is what drives the growth of PMOs and all areas, and not the other way around.


LinkedIn Profile - CLICK HERE
LinkedIn Group - CLICK HERE 
Articles by Alyce Reopelle - CLICK HERE
Visit my Personal Website - CLICK HERE

Advertisements B