Analysis Matrix

Design patterns can help analysts identify and organize variations successfully. After the problem domain has been organised around variation, it becomes easier to see how design patterns can be used to create a high-level design of the application. The analysis matrix helps to understand the problem domain, and then implement it. It is a simple analysis tool that is a useful starting point for capturing variability in concepts and thinking about the problem domain.

  1. Identify the most important features in a particular scenario and organise them in a matrix. Label each feature with the concept that the feature represents.
  2. Proceed through other scenarios, expanding the matrix as necessary. Handle each scenario independently of the others.
  3. Expand the analysis matrix with new concepts.
  4. Use the rows to identify rules.
  5. Use the columns to identify specific situations.
  6. Identify design patterns from this analysis.
  7. Develop a high-level design.

Separate the requirements into possible scenarios.

The far left column of an analysis matrix is the essential concept that represents a feature/function within the software. Each row of the matrix represents specific, concrete implementations of the generalised concept described in the row. Each column in the matrix represents the specific implementations for a given case.

In general, any pattern that uses polymorphism could be present in an Analysis Matrix, e.g. Strategy, Bridge, Decorator, Template, Observer, Composite, Command, Proxy, Visitor.

The Analysis Matrix is focused on variations in concepts. It is used at the conceptual level of design and analysis.

Analysis Matrix is a good way to discover variations. We are motivated by information overload, where we don’t know how to organise and group requirements.

We look for places where the OCP applies — where do we want to be open for extension?

The AM is a two-dimensional grid, and we can have mini-matrices within the matrix to drill down into features.

Rows represent concepts, e.g. calculate shipping, whereas columns represent cases, e.g. USA customer, Canada customer. The intersection of a row and a column is usually a concrete class/object of some description. Row gives us the interface for this object. Row is quite often a Strategy pattern.


To the index!