Document Archeology

Document archeology is a technique of searching through existing reports and files for underlying requirements. It is best used when you have some existing or legacy system, and plan on modifying or renewing it.

Document archeology involves determining the underlying requirements by inspecting the documents and files used by the organization. It is not a complete technique, but rather should be used in conjunction with other techniques, and only with caution. Document archeology is reverse-engineering the documents used or produced by the current work. In other words, you dig new requirements out of the material used by the old work. Along the way, you look for requirements that should become part of the new product. Obviously, not all of the old work will be carried forward. But where a current system exists, it will always provide plenty of material that is grist for your requirements mill (see Figure 5.11).

Figure 5.11.

In document archeology, you start by collecting samples of all documents, reports, forms, files, and so on. Gather anything that is used to record or send information, including regular telephone calls. User manuals are rich sources of materialthey describe a way to do work.

Inspect the documents you have collected (for simplicity's sake, the term "document" means anything you have collected) looking for nouns, or "things." These can be column headings, named boxes on forms, or simply the name of a piece of data on the document.

For each "thing," ask these questions:

• What is the purpose of this thing?

• Who uses it and why?

• What are all the uses the system makes of this thing?

• What business events use or reference this thing?

• Can this thing have a value? For example, is it a number, a code, or a quantity?

• If so, to which collection of things does it belong? (Data modeling enthusiasts will immediately recognize the need to find the entity or class that owns the attribute.)

• What is the thing used for?

• Does the document contain a repeating group of things?

• If so, what is the collection of things called?

• Can you find a link between things?

• What process makes the connection between them?

• What rules are attached to each thing? In other words, what piece of business policy covers the thing?

• What processes ensure that these rules are obeyed?

• Which documents give users the most problems?

These questions will not, in themselves, reveal all the requirements for the product. They will, however, give you plenty of background material and suggest directions for further investigation.

When doing document archeology, you search for capabilities from the current work that are needed for the new product. This does not mean you have carte blanche to replicate the old system. After all, you are gathering requirements because you plan to build a new product. However, an existing system will usually have some capabilities in common with its replacement.

But be warned: Because a document is output from a current computer or manual system, it does not mean that it is correct, nor does it mean that it is what is wanted by your client. Perhaps the document serves no useful purpose, or it needs heavy modification before it can be reused successfully.

We suggest that you incorporate document archeology into your data modeling approach, because most of the answers from the questions listed earlier are commonly used in the latter discipline. Of course, some document archeology is used as a foundation for object-oriented development. The current documents, if used cautiously, may reveal the classes of the data. They may also reveal the attributes of data stored by the system, and sometimes suggest operations that should be performed on the data.

As a rule, we always keep artifactsdocuments, printouts, lists, manuals, screens, in fact anything that is printed or displayedfrom our interviews because we often refer back to them. Make a habit of asking for a copy of any document or screen that is mentioned.