So, you’ve met with your stakeholders and elicited information about their business processes, business needs, or how the system works today. How do you actually turn this into requirements documentation?
In what follows, I’ll share my 4 step process to getting from initial elicitation meetings to a complete and validated requirements document.
Step 1: Document Meeting Notes
Instead of sitting down and attempting to translate what you’ve just heard into usable documentation, I’d recommend first typing up meeting notes that are more representative of “stream of consciousness” writing. Read through your hand-written notes and type not just what you managed to get down on paper but everything else these reminders trigger. Your first goal is to get down on paper “what you heard” and then “what you were thinking”. I like to use parenthesis or brackets to call out implications of what I heard, for example:
Jane noted that they use they use search to find newly registered customers and verify their credit card transactions went through successfully. [Note to self: why would a credit card transaction not go through? Are we not validating this before registering the customer?]
Writing up notes typically triggers all kinds of questions we simply did not think of while actively engaged in dialog. This is OK.  Although you can minimize your follow-up questions after meetings, some follow-up questions are simply part of the process.
Step 2: Ask Follow-Up Questions
If you find big gaping holes, you will want to go back to your subject matter experts and ask some follow-up questions. If your questions are specific to one feature or you do not expect the answer to have a significant implication, you can ask those questions during validation. Be sure to capture those questions so you don’t lose them, either in an requirements issues list or within the documentation you are creating.
Step 3: Analyze and Document
Now it’s time to begin to analyze the information you’ve pulled together. Using a structured template can help you analyze the problem space. I like use cases because laying out the functionality in a sequence of steps, with alternate paths and exception flows helps me think through all the possible scenarios and identify gaps in my thinking. But there are many different requirements documentation formats a BA can choose from. Choose the one that best solves the problem to be solved by your project.
Once you’ve drafted documentation and before you begin to send it out for review, let it rest for a day or two. Go back with a fresh perspective as a potential new reader of the documentation.
- Is it clear?
- Would you be able to gain an understanding of the system?
- Could you add on to it as the system changes or you learn more about the project?
We often think about the usability of our systems, but rarely about our documentation. The common thinking is that any documentation is better no documentation. I disagree. No documentation is better than bad documentation.
Step 4: Validate the Documentation
Once you have a draft ready to go, you’ll want to validate your documentation with your subject matter experts. This activity closes the loop (for them and for you) by presenting back the details of what you understand. If your subject matter experts are new to this type of documentation, you may want to host a brief tutorial on what the document is and how it will be used.
Always be very upfront about the kind of feedback you expect and very open to comments like “you didn’t get that right.” In most situations, I’d recommend a brief in-person or over-the-phone walk-through of the document and this is a great time to ask your smaller follow-up questions.
Nothing gets a discussion going like you admitting you did not get all the details in the original discussion. It makes people more open to provide feedback. On occasion, you and your team will identify some significant holes to be filled. Significant holes are best filled in new elicitation sessions, not in a validation meeting. So, back-up, conduct the elicitation session, and work your way back through the four steps.
>>Improve Your Requirements Writing Skills
Looking for practical ways to reduce requirements defects while also improving your requirements specifications? Check out one of our business analysis training courses:
At Bridging the Gap, we help you start your business analyst career and gain confidence in your business analysis skills.
