Business Analysis is mainly about communication, where your ultimate goal is to understand, summarize and communicate your stakeholders requirements. From business processes models to detailed solution requirements and UML diagrams, your deliverables and requirements packages will be at the center of your work as a Business Analyst.
However, these deliverables should not be the end of your work; they are only the means to work more closely and efficiently with your stakeholders so that everyone will be on the same level of understanding about the requirements.
How can you use your BA deliverables to support a project team through the implementation of a solution? Let’s explore this dimension in this third of a 4-posts series.
In the Taking Business Analysis deliverables to the next level series, I explore the various ways a Business Analyst can use deliverables for more than pure requirements documentation. Whether they are used for improved collaboration, team support our as an insurance policy, BA deliverables can be brought to the next level as long as they meet quality standards and are relevant to stakeholders.
The challenge of communicating requirements
Eliciting and analyzing requirements is one of the core responsibility of a BA. However, it doesn’t end there. If you can’t communicate those requirements, chances are they will never come to life to fulfill your stakeholders needs.
The ability to communicate requirements using various formats and methods is a defining characteristic of a good BA. Communication has to occur often through the life of a project, not only in the first stages of it. It also has to reach a wide (but appropriate) audience in order to be effective.
Effective communication is a discipline in itself, but you can also use your BA deliverables to your advantage in order to improve collaboration and communication with your stakeholders.
BA deliverables as collaboration tools
Communication is essential, yet many BAs try to create the URD (aka the Ultimate Requirements Document) instead of focusing on the real needs of their stakeholders. In the world of communicating requirements, one size rarely fits all.
Packaging requirements in various formats to facilitate their understanding by all your stakeholders should be one of your main priority once they are elicited, and it should remain one until the complete delivery of the solution.
User stories are a good starting point to identify which requirements matter to which stakeholder since one of their main focus is the user. Organizing requirements from a user perspective means more emphasis and details are put on these requirements, while keeping them in context of the whole solution and other requirements. By preparing multiple packages, you will actually create different perspectives on the same requirements, just like a single story could be told differently by its various characters.
Well-packaged requirements will be a key input to successful walkthroughs, by making them useful and relevant for participants. They also help to get a better understanding of the impacts of a change to requirements, by putting these changes in a context relevant to each stakeholder. In the end, they become useful documents for your stakeholders.
But don’t forget that packaging requirements only supports more effective communication; it doesn’t imply ignoring other requirements nor meaning they’re less important. Be sure to manage your stakeholders expectations before heading this way.
Benefits of requirements packages for implementation teams
Requirements packages are not only useful on the customer side, they are also essential for your various implementation SMEs. While customer-centric packages focus on the business, process side of the solution, implementation-centric packages will usually focus on the system side of the solution (while still providing business context to understand the solution as a whole).
- Development teams will benefit from packages focusing on system behaviors and on how end users will interact with the solution. From my experience, use cases are especially useful in this context, as well as UML diagrams such as state, activity or sequence diagrams. Entity-relationship diagrams can also provide key information for dev teams.
- Testing and training teams are usually interested in the same packages as your customers since their ultimate goal is to ensure that the solution supports expressed needs. Packages created for the development teams can also be useful, especially when the solution isn’t constructed yet.
- Support and operations teams will also benefit from specific requirements packages to ensure a smooth transition to the effective use of the solution in the organization. User-centric packages (containing user cases, scenarios, and other user-focused artifacts) will be useful to understand how the system should be used and guide users accordingly while system-centric documentation will be useful to understand how the system should be built and how it should be fixed, once the solution is deployed.
Requirements packages can be useful from the beginning to the end of a project, and even after the solution is delivered. Well-defined and maintained packages will also help Business Analysts (who can be you!) when the time will come to improve or replace the solution, giving them a head-start in documenting and understanding the current solution.
In the next and last post of this series, we will explore how BA deliverables can be useful as an insurance policy for your projects.
If you missed the previous posts of this series, you can start with the introduction post. And if you don’t want to miss upcoming posts, just subscribe to Eric the BA newsletter below!
Do you like what you’re reading?
Did you get other benefits from packaging requirements in various ways? Share your thoughts in the comments below!
