Field Notes

In practice, almost any kind of pattern that involves polymorphism could be present in the Analysis Matrix. Of the patterns I've presented, this would include Bridge, Decorator, Template, and Observer. Other patterns I have used in an Analysis Matrix are Composite, Proxy, Chain of Responsibility, Command, Iterator, Mediator, and Visitor.

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 showed up in the leftmost columns) and then implement them with design patterns.