ArgonDigital - enterprise automation experts

Share This Post

Business Analyst Tip: 7 +/- 2 is a Guideline, Not a Law

Business Analyst TipsSoftware requirements models can benefit from the application of the 7 +/- 2 guideline – provided business analysts remember it’s a guideline, not a law. This guideline, which Brent Hoffman discussed last summer, came up in a discussion we were having the other day at ArgonDigital.

As Hoffman mentions, it’s a handy guideline when creating visual software models. But, since George A. Miller himself says this really doesn’t apply to printed material, why does it apply to software requirements models? Because it aids with two things critical to requirements:

  1. It allows people unfamiliar with the subject matter to more quickly understand it. If I’m unfamiliar with a process, reading through 50 steps to understand it can be difficult. On the other hand, if I see 5 high-level steps, I can understand them pretty quickly. Then, I can look at sub-processes of around 7-12 steps each and understand them as well. None of these are so long that I lose (or, forget) context before I finish.
  2. It allows people familiar with the subject matter to find gaps. Hand someone a grocery list with 25 items on it and ask them “What else do we need?” and they may have trouble answering. On the other hand, if the list is organized by categories – as fruits & veggies, meats, dairy, staples, drinks, and snacks – finding gaps is much easier.

Some of the primary use cases for software models are to communicate information and provide a framework for determining if you have all of the information. Using successive decomposition, it’s much easier for the novice to understand information and for the reviewer to look for gaps.  

Unfortunately, sometimes people take it too far, thinking that it means that you should always limit the amount of information on one page of a model to 7+/- 2 items. It doesn’t, it just means to use a meaningful categorization or organization which allows consumers of the information to process it in “chunks”. 

Given that the person reviewing my list may not categorize items the same way I do, having the entire list on one page makes it easier to review. Someone reviewing the drinks might think “Drinks…oh yeah, we need coffee…I don’t see it here…some people also consider it a staple…ah—there it is.” If the staples were on a different page from the drinks, the reviewer would have to flip to another page to see if coffee is on a different list, losing their context. 

When the information for the categories will be compared or contrasted or when the placement of items in a category is at least somewhat subjective, it can be useful to have it all on one page—providing it reasonably fits.  The feature tree is a great example of this.

7 +/- 2 — Guideline, not law.

Business Analyst Tip: 7 +/- 2 is a Guideline, Not a Law

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage