Let's Define Those Detailed Requirements!

Today I'm continuing what is becoming an 8-part series on our 8-Step Business Analysis Process Framework.

(If you'd like to check out the first 4 parts of the series, you can find them on the Successful Business Analysis newsletter - while you are there be sure to hit "subscribe" to get notifications on all my new articles.)

First of all, let's be incredibly clear. This article is not just about getting started "writing the requirements already." Coming into this step, you've gotten clear on the real business problem to be solved, the high-level solution scope, and planned the business analysis effort that includes not only the deliverables you will create but who needs to be involved in those deliverables.

With this preparation in place, you are truly ready to start discovering, analyzing, and validating the detailed requirements deliverables.

This work is so incredibly important. Detailed requirements provide your implementation team with the information they need to implement the solution. They make scope implementable. That's why people want us to just jump to this step! Because with the requirements in place, implementation can happen.

(That's not to say that teams don't implement things without requirements all the time but most often that pattern requires a frustrating amount of rework.)

Without clear, concise, and actionable detailed requirements, implementation teams often flounder and fail to connect the dots in such a way that delivers on the original business case for the project. 

Your key responsibilities in this step include:

• Eliciting the information necessary to understand what the business community wants from a specific feature or process change. Business analysts use a variety of different elicitation techniques, including observation, walk-throughs, structured interviews, documentation reviews, and surveys to discover information that helps them analyze the requirements.
• Analyzing the information you’ve discovered and using it to create a first draft of requirements documentation containing the detailed requirements for the project. You'll have defined WHAT documents you'll create in step 4, here is where you actually sit down and create those documents. One quick tip is that nuances are incredibly important. It's in the nit-picky details like leaving "is" out of your use case steps and clarifying terminology that you'll pick up on otherwise missed requirements.
• Reviewing and validating each deliverable with appropriate business and technology stakeholders and asking questions to fill in any gaps. I see new business analysts get really caught off guard by the level of elicitation and validation required. Even during this step of defining the detailed requirements, communication and presentation are incredibly important. You are the requirements author, but not the owner - the business stakeholders own the requirements.

This process sticks whether you are analyzing the details of the user stories for the next spring, or analyzing dozens of business processes and use cases for a major project.

One thing I've found to be incredibly important, however, is to consciously sequence your deliverables to support the forward momentum of the project. It's important to pay attention to the project’s critical path, reduce ambiguity and complexity, and generate quick wins are all factors to consider when sequencing your deliverables.

It's also important to establish a rhythm with both your business and technical stakeholders. A lot of teams benefit from having time on their calendar each week that is set aside for elicitation and validation work. That way you aren't scrambling to find times week-to-week for requirements work.

Over to you - What are your best practices when it comes to defining the detailed requirements? Please share in the comments!

And if you want the entire deep dive on the 8-step business analysis process framework, be sure to check out the BA Essentials Master Class, which goes through each of the 8 steps in more detail, and includes practical guidance on how to handle the most common challenges that pop up on projects.