Do Document Archaeology (Process Notes 2.1.6)

Document archaeology entails determining the underlying processes and requirements by inspecting the documents and files that the organization uses. It should not be used on its own as a requirements-gathering technique, but as a prelude to more intensive interviews and as the basis of modeling efforts.

In document archeology, you begin by collecting samples of all documents, reports , forms, filesin fact, anything that is used to record or send information. Regular telephone calls should not be excluded.

Inspect the document (for simplicity's sake, the term "document" here means all of the above) 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 noun, ask these questions:

What is the purpose of this thing?
Who uses it, why, and what for?
What are all the uses the system makes of this thing?
If I have thing A, must I also have thing B, and must I not have thing C?
Can this thing have a value? For example, is it a number or a code or quantity?
If so, to what collection of things does it belong? (Data modeling enthusiasts will immediately recognize the need to find the class that owns the attribute.)
What is that thing used for?
Does the document contain a repeating group of things?
If so, what is the collection of things called?
Can I find a link between things?
What process makes the connection between them?
What are the rules 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 the users the most problems?

These questions will not in themselves reveal all the requirements for the system. They will, however, give you plenty of material and direction for further investigation. We also suggest that you use document archeology as part of your data modeling approach.

Make Requirements Video (Process Notes 2.1.7)

Video can be used to co-develop software. The users and developers participate in workshops and brainstorming sessions, and the proceedings are videoed. Interviews and on-site observations are also recorded. The videos are used to first record, and then confirm, the proceedings . In addition, videos can be shown to developers who do not get the opportunity to meet face-to-face with the users.

Video can be used as an adjunct to interviewing and observing the users in their own workplace. Users have their own way of accomplishing tasks , their own ways of categorizing the information that they use, and their own ways of solving problems that have worked well for them in their own situation. Thus, by using video to capture the users at work, you are capturing their ways of doing their jobs and their concerns, and not imposing your own expectations and preferences.

Video can also be used in a more structured way one business use case at a time. Select the business use case and ask the users to work through typical scenarios that they encounter with that activity. As they work, the users describe the special circumstances, the additional information they use, the exceptions, and so on. The shrugs, grimaces, gestures, and other body language that are normally lost when taking notes are faithfully recorded for later playback and dissection.

Run Use Case Workshop (Process Notes 2.1.8)

This workshop is conducted with the participation of the appropriate customer/user and the requirements team. The first segment of the workshop generates the scenarios; this effort needs input from the users/customers. The idea is to talk through a use case/event and to extract from the user the essential things that have to happen when this business event takes place. You are trying to define a series of user-recognizable steps that complete the work of this business use case. You ask the user to verify/improve/change the steps that you have written down. The resulting use case scenario is a very rough sketch of the requirements for the use case.

After the use case workshop, the requirements analysts go back to their offices and derive and specify the individual requirements from the knowledge in the use case scenarios.

Buy on amazon.com >>

Robertson S., Robertson J.

<< Previous page

Table of contents

Next page >>