At ArgonDigital, we consistently tout the invaluable benefit of using models in your requirements process. In many cases, models are more than enough to communicate the intended functionality to all stakeholders. This is especially true if you have been using models in your process for some time and stakeholders know what to expect. However, in nearly all cases, every stakeholder will not be familiar with your process. Therefore, your requirements document must stand alone in telling the story. The issue with this is that your audience will always be highly varied. Everyone from engineers to non-technical business users must be able to consume your requirements deliverables.
Most organizations have standardized on some form of requirements deliverable, such as a BRD, PRD, or FRD. However, in most instances, this document is heavy slanted toward one side of the organization based upon whose job it is to create it. If your Business Analysts report up through IT, the document is typically very unfriendly to business users. If they report up through the business side of the organization, the document is typically not sufficient from your engineering group’s perspective.
Here are some tips for ensuring that your requirements deliverables can be consumed by all stakeholders:
1. Tell a Story
If creating a template to define the organization-wide expectations for requirements deliverables or simply creating a one-off requirements document, it is important to tell a story in your document. Stop, think, and identify how the document should flow to explain the story. All too often, we are tempted as Product Managers and Business Analysts to group all of our models together, all of our user stories elsewhere, and so on. This makes the document flow very poorly and extremely difficult to understand.
Think about the structure of your deliverable. I have found that beginning with your scope information and bounding models, followed by feature-by-feature groupings of models and requirements has worked for me to tell the story of what we are trying to accomplish from a functional perspective. In addition, it is helpful to have your features flow in the logical order that users would interact with them in the finished system.
2. Create an Instructional Document
If you plan to use a standardized xRD template in your organization, it can be helpful to create an instructional document. This document is quite literally a ‘How to Read our xRD’ instruction manual. It is important to keep this document short and user friendly, otherwise it won’t get read. Many Business Analysts have trouble getting stakeholders to read their xRD documents, let alone an instructional document on how to read the xRD. You can even create a very short slide deck or video if that is the preference of those consuming your requirements deliverables.
3. Segment Your Document by Audience
In many cases, there is quite a bit of information in your deliverables that applies to your technical consumers that won’t apply to your business consumers and vice versa. A way to combat this is to segment your document. Try putting information that applies to your technical consumer, such as mapping matrices, in the appendix. Just make sure to link to it in the document so that navigation is simplified.
4. Create Separate Documents
When all else fails, create separate deliverables for your different audiences. At first, this may seem like a waste of time. If you’re like most BAs, free time is a very scarce resource. However, look at the additional time spent on creating multiple versions of a deliverable as an investment. In many cases, you will find that your validation and rework time is reduced by more than the amount of time that you spent creating multiple, audience-targeted versions of the deliverable.
As always, feel free to submit your questions and comments.
