A New Approach
A critical first step in solving the analysis challenge is defining the terms we will use to communicate. The words "problem," "objective," "requirement," and "specification" are particularly important. Using the same words to mean different things, or different words to mean the same thing, is a common source of misunderstandings. The approach I describe here uses the following definitions.
The problem addressed by the project is a description of the way the thing works today. The objective is a description of the way the thing should work in the future, when the project is complete. The requirement is the difference between the way the thing works today and the way it must work in the future. That is, requirements are the changes that must be made. The specification provides a detailed description of the new element that will satisfy the requirement. It may be a mock-up of a new or changed screen, a file layout, a business process diagram, or any concrete, unambiguous representation of the thing being changed that facilitates communication for the purpose of validation. The important thing about these definitions is that they accommodate the recording, without modification or interpretation, of all of the information we will gather.
The key to the approach described here lies in applying this structure (i.e., problem - objective = requirement) consistently; whether "the thing" being described by the interviewee is a business process, an organization structure (e.g., roles and responsibilities), or the IT systems and infrastructure supporting the business. The result is the multidimensional matrix shown in Figure 1. Each piece of system functionality is enumerated, and the question of whether or not it will be changed is explicitly addressed. Each piece of system functionality is linked to a task within a business process and each task is linked to the individual or individuals within the group or groups that perform it. When analysis is complete, all the cells in each layer of the matrix will have contents, and each cell in any layer will be linked to a related cell in each of the other layers. The contents should be consistent within each layer of the matrix but each layer will likely have a different type of content (e.g., business process diagram vs. org chart vs. UML diagram). The matrix is easily implemented using a spreadsheet. The linkage between layers can be as simple as a text reference within a cell that manually leads the reader to the related cell within another layer. At the other end of the spectrum, depending on the tools available and the technical skills of the analyst, a Web-based, hypertext format can also be used to allow a broader audience of readers to navigate the matrix automatically. This basic structure can be extended in both depth and breadth to accommodate additional information-gathering needs.
It is often desirable to utilize a layered, hierarchical approach to documenting each of the contexts: organization, process, and technical. This makes is possible to capture and organize, for example, all of the related IT systems supporting a business function and then "drill down" with separate sheets to each of the impacted systems and their specific functionality. The drill-down can continue to the level of individual fields on a screen that are then tied to sub-steps in a business process that has been similarly decomposed. This can be particularly useful in documenting exception processing when the project addresses a new system that automates a previously manual process. It can also help to materially decrease the probability of unintended impacts to other IT systems.
Figure 1. Requirement Communication Matrix