Design Patterns Explained

Chapter 2O • The Analysis Matrix 3O1
For example, if in our e-tail system I included requirements on
printing sales tickets and found the following variations:
• U.S. sales tickets need headers
• Canadian sales tickets need headers and footers
• German sales tickets need two different footers
I would include this information in its own row, each entry relating
to the format of sales tickets. I would implement this row's requirements
with a Decorator pattern.
Although the Analysis Matrix rarely captures all aspects of a particular
problem domain, I have found it useful for at least part of most
problem domains. I find it most useful when I am given so many
special cases that I can't get my head around the big picture.
It is usually worse than this. Rarely are different cases of requirements
stated to analysts or developers in any coordinated fashion.
This does not significantly complicate the Analysis Matrix process,
however. In these situations, I take a feature and look in the leftmost
column and see what concept it is a variant of. If I find the
concept, I put the feature in that row. Not being able to find such a
concept indicates I must create a new row.
In extreme situations, the Analysis Matrix may be the only way to
get a handle on things. I once had a client that literally had dozens of
special cases. Each case was a separately developed document
control system. The problem was to integrate all of these document
control systems together. So many special cases were present (there
were also dozens of rows) that it was impossible to think about the
entire problem all at once. The analysts did not have a good conceptual
grasp of what was involved. They just talked about general
rules and exception cases. By considering each case individually, I
was able to abstract out the common data and behavior (which
Applicability of the
Analysis Matrix
More useful as
problems get bigger