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. However, it is a necessary task!
How else will the business know that they are getting what they want? How else will developers know what to build and testers to know what to test? Given the large scope of requirements documents and even models, I found it’s useful to break them down into smaller chunks that folks 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 these 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 the 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 holds true also for developers and testers – these people usually are not working on the entire system but instead on individual modules or pieces. Walking them through sections of requirements documents and models 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 taking up other peoples’ time.
Using working memory to focus your time as a business analyst and product manager is one of the most important skills I’ve learned. Today there are so many roles and responsibilities thrust upon our profession that having the ability to use time efficiently is invaluable. Furthermore this technique is a more effective way to perform reviews as it ensures people’s attention due to the relevance of the content. Therefore utilizing working memory is a win-win – more efficient and effective!
