The Magic of 7-9
If you recall from psychology 101, most people can only hold 7-9 items in their short term memory. To learn more pieces of information, you need to transfer those items to your long term memory. There are two ways that you can do this, either by rote memorization or by creating a deeper understanding of the items. I am not really capable of memorizing thousands of requirements, so this human limitation has implications for working with requirements.
On a recent project we were given a set of around 500 pseudo-requirements. To this we added another 800, for a total of approximately 1300 pseudo-requirements. These pseudo requirements were statements of need made by business and technical users that were not well formed requirements and in many cases made no sense at all. We went through this list several times with the client to clean up the pseudo requirements and turn them into actual requirements by looking only at each requirement in isolation. However with such a large list it was impossible to retain the information to be able to make sense of the requirements as a whole.
As a first step we broke the requirements into 23 categories that made sense to the client. We worked with them to make the categories as orthogonal as possible and created strict definitions for what types of requirements would go into each category. We then began to categorize each requirement. After removing many duplicate and nonsensical requirements, we ended up with about 900 good requirements with about 40 requirements in each category. With the requirements broken up by category we had a much easier time understanding what we had and we began to work through the requirements not as individual requirements but as to how they related to each other. This made it possible to remove the duplicates and begin to find holes and commonality between requirements.
Even with 40 requirements it is difficult to find missing requirements, so in the next step, we worked to segment the requirements yet again. After looking at the low level requirements in each category, we developed around 5 high level requirements for each category that captured the essence of the category. We then mapped the low level requirements to the high level requirements with about 8 low level requirements for each high level requirement. Once we did this we were easily able to manage the requirements. In addition, this mapping enabled us to find additional high level requirements when we could not map a low level requirement to an existing high level requirement and enabled us to much more easily find missing low level requirements when a high level requirement did not have many requirements linked to it.
We ended up doing several other mappings, including to use cases, systems and entity-relationship diagrams (ERDs) but the mapping between 23 categories to 120 high level requirements to 900 low level requirements was the first critical step in creating the structure necessary to be able to comprehend a very large number of requirements. As a side note we actually created another set of 4 categories that we mapped our 23 high level categories to as well. I don’t think it is a coincidence that our natural tendency was to only have around 8 items in each category before being forced to decompose to the next level of detail.
The take home lesson here is that to properly review, understand and even remember a large number of requirements, you must decompose them into logical units. The human brain has a hard time working with more than 7-9 elements at a time and so the result is that you will need to categorize your requirements into natural groupings of 7-9 requirements and you will need to categorize your groupings similarly.
On a recent project we were given a set of around 500 pseudo-requirements. To this we added another 800, for a total of approximately 1300 pseudo-requirements. These pseudo requirements were statements of need made by business and technical users that were not well formed requirements and in many cases made no sense at all. We went through this list several times with the client to clean up the pseudo requirements and turn them into actual requirements by looking only at each requirement in isolation. However with such a large list it was impossible to retain the information to be able to make sense of the requirements as a whole.
As a first step we broke the requirements into 23 categories that made sense to the client. We worked with them to make the categories as orthogonal as possible and created strict definitions for what types of requirements would go into each category. We then began to categorize each requirement. After removing many duplicate and nonsensical requirements, we ended up with about 900 good requirements with about 40 requirements in each category. With the requirements broken up by category we had a much easier time understanding what we had and we began to work through the requirements not as individual requirements but as to how they related to each other. This made it possible to remove the duplicates and begin to find holes and commonality between requirements.
Even with 40 requirements it is difficult to find missing requirements, so in the next step, we worked to segment the requirements yet again. After looking at the low level requirements in each category, we developed around 5 high level requirements for each category that captured the essence of the category. We then mapped the low level requirements to the high level requirements with about 8 low level requirements for each high level requirement. Once we did this we were easily able to manage the requirements. In addition, this mapping enabled us to find additional high level requirements when we could not map a low level requirement to an existing high level requirement and enabled us to much more easily find missing low level requirements when a high level requirement did not have many requirements linked to it.
We ended up doing several other mappings, including to use cases, systems and entity-relationship diagrams (ERDs) but the mapping between 23 categories to 120 high level requirements to 900 low level requirements was the first critical step in creating the structure necessary to be able to comprehend a very large number of requirements. As a side note we actually created another set of 4 categories that we mapped our 23 high level categories to as well. I don’t think it is a coincidence that our natural tendency was to only have around 8 items in each category before being forced to decompose to the next level of detail.
The take home lesson here is that to properly review, understand and even remember a large number of requirements, you must decompose them into logical units. The human brain has a hard time working with more than 7-9 elements at a time and so the result is that you will need to categorize your requirements into natural groupings of 7-9 requirements and you will need to categorize your groupings similarly.
posted by Anthony C. at 5/19/2006 08:19:00 PM
3 Comments:
It is unclear to me that you are talking about functional requirements or non-functional requirements. This is the first categotization that needs to be clear.
The same 7+/- rule can apply to team size.
David, I appreciate the feedback. I completely agree that non-functional vs. functional requirements is one of the most important classifications. It has been our experience that a majority of requirements end up being non-functional (typically business rules) and often times you end up awash in a sea of non-functional requirements which makes it difficult to ensure that you have identified the functional requirements unless you split them out.
Post a Comment
<< Home