Improving Requirement Gathering Documentation From A Salesforce POV

This is a topic I feel strongly about due to the impact it can have on a Salesforce implementation.

I have seen different approaches from not taking notes (only recordings that are transcribed) to the word-to-word notes (I do this), and I feel none of them get the job done in a useful way. While transcribing might be better it takes too much time and is really dependent on the person doing the transcribing. Also, by the time the notes are shared with the wider audience certain points might be forgotten. Running notes on the other hand are easier to share but have a higher chance of mistakes being introduced.

I think the requirements documentation should move away from notes created based on slides chock-full of questions, to a living document with a better structuring that everyone in the room is forced to think into.

There are two parts here, one is the document structure itself and the second is the process of requirement gathering. The latter is something I will not get into as it varies wildly person-to-person and depending on the medium (in person vs remote). The structure however IMO can be common.

This is the structure I have finally come down to

Context

This would cover the basics about the requirement and even a brief of the as-is state of things.

Pain points

While the first section might tell us more about the requirements at large, this section needs to focus on the human or business challenges that we are trying to overcome with this requirement.

Success metrics

This section is only as good as the leadership team that is involved in the project. It needs to be a number and achievable. It should not be an adjective. In technology implementations this should be in terms of time saved in human hours, percentage reduction in errors, or money saved.

Questions

This should not be a bullet point list, but a table with four columns. Questions, answer provided, ETA for open questions and the person who is responsible for providing the answer. This is better than running notes as the context of some of the statements made might be missed. Even if something new was mentioned that was not part of my original questions list, I create a corresponding question and then add the response. This also eliminates the need of a separate decisions and actions items section.

Process map

This section could have the embedded process map that was shared as part of the requirement or it could also be accompanied by the revised one made during the requirements discussion based on the details provided. Once the requirements process has finished this section could be moved above the questions section.

Data points

What are the key fields, or attributes that need to be captured as part of this requirement. What will be filled by people vs what will be populated by a system? Who is responsible for ensuring accuracy of this field and who will use it for what step of the process? Who should be allowed to see it and what are the risks from a privacy and regulatory point of view of storing this information? These are some of the questions that need to be answered apart from understanding the type of a field and its naming convention.

Most of these questions come up post-fact as of now as part of design review or as part of a user-acceptance testing, and this needs to change.

User interface

From a Salesforce POV, this comes down to understanding how the fields mentioned above needs to be prioritised, what actions should be on the page, how list views should be and so on. That said, most of that would be covered as part of the requirements itself. This section should be used to add reference or prototype screenshots wherever possible. Avoid taking that up in the design phase.

Analytics

While the reporting questions would be addressed above, it is good to add the report output structure the way business would like to see it. By doing this you would be covering some of the implied or assumed requirements that would only reveal itself later on.

Assumption

This section needs to be updated while working through the questions. It is very important to mention who made the assumption, as a lot of assumptions could come in from the business teams as well related to system performance.

Out of scope

Anything that is explicitly stated as not required in response to questions should be captured here. Anything that cannot be achieved should also be added here and explained to the business teams.

This is what I’m using now and I will revisit this after a couple of months with updates on how it went.