Soliciting requirements from an SME

Soliciting requirements from an SME

When soliciting requirements from an SME or Subject Matter Expert, what is the most important information that you need to capture and how do you know that you have captured it? What would your response to this question be?
Capturing requirements is an art and it plays a key role in the effective and successful delivery of any project.
When I work with Business Analysts and project teams I find that there are often gaps in the way that requirements gathering is approached.  So I’ve been asked this question: “When soliciting requirements from a subject matter expert or end user, what is the most important information that you need to capture and how do you know that you have captured that information?


My initial response to this question is to say that the BA needs to ensure that they ask enough questions in order to fully understand how current business processes work.
So much of what happens in a project is based on a change to current work process, without fully understanding what happens currently you have no idea what you need to create in order to create the changed world.


Really asking the SME how things work down in the detail is very important.  If in asking the questions, things don’t make sense, this is a great sign for me that there are pieces of information missing.  I will then want to go back and ask more questions, validate what I’m being told.


By doing this you are able to see, any areas where there are additional processes impacted, system that interface, those sorts of things.  If you only take what you’re told on face value, you miss out on a lot, and subsequently leave your project open and risky.


Why?  Because anywhere that you, the BA, as the knowledge holder for the project, don’t understand fully what happens or is going to happen leaves an unknown, a gap that can and will create a risk that something may go wrong.


You know that you’ve capture enough information when you have a solid understanding of the way that the current processes work, and then what your changed process is going to look like.  Only when you have this information down and detailed can you then start to bring systems into the picture.


Start with the system and you’re coming at things from the wrong way.


Even when talking about a project that is predominantly about system change, you still need to be asking questions about the process, as this is what drives what happens.


Therefore paint the picture of what the current processes are.  Then paint the picture of what you want any new processes to be.  The gap is what needs to be filled with your project – how to get from AS IS (Current State) to TO BE (Future State).
What I have discussed here is the key role of a BA on a project team.  If they do this well, then they set the project up for success, so they play a vital role on any project team.




Written by Karen Munro
*Photo courtesy of Stuart Miles at