How do you get your stakeholders to review your business requirements document?
Everyone hates going through and reviewing large documents – no one wants to sit down and read a 300 page software requirements specification (SRS) or business requirements document (BRD) and provide feedback. So how do you get your stakeholders to engage in the review? Make it more consumable for them!
Think of it this way: if your team doesn’t fully review your business requirements document, how will the business know they are getting what they want? How will developers know what to build, or testers to know what to test? Given the large scope of requirements documents and even models, it’s useful to break them down into smaller chunks that people can process in their working memory.
Working memory is the part of the mind that holds information in order to perform tasks, usually for the purpose of achieving a goal. Comprehension, logic, and reasoning all require working memory in order to be accomplished – therefore working memory is a big part of completing reviews with the various stakeholders involved in requirements.
Traditional research has held that working memory typically can hold 7 ± 2 objects – this originates from a study performed by George Miller in the 1950’s regarding how much information a human can process at once. More recent research has suggested that this number is as low as 3 or 4 objects. This research provides us with a starting point for how to “chunk” up the process of reviewing requirements documents and models; we should be aiming for a range from 3 to 9 objects during any point in the review. Examples of this include all of the systems touching a single system in a System Context Diagram, steps performed in a Process Flow by a single person, or a department in an Org Chart, and the functional requirements for a single feature in a SRS.
By breaking down the review into chunks, you make it much easier for your stakeholders to understand the content and not lose themselves in a deluge of information. This also allows you to target specific audiences during your review sessions – most of the time business stakeholders only know a small piece of the information that is used to develop requirements for a system. By chunking models and requirements documents into the small pieces that are specifically relevant for your audience, you can quickly review important information with the right people.
This also holds true for developers and testers – these groups usually are not working on the entire system but instead on individual modules or pieces. Walking them through sections of business requirements documents that pertain specifically to them allow them to spend less time in review sessions and also to focus on the content that they will be working most closely with. At a recent client site visit, it was amazing how effective this proved when the folks who were configuring the system sat in on sessions pertaining to their module – they were able to dive right in and ask the questions specific to their needs without having to be concerned about expending a lot of time on it.