Process Three: Gather Information | Requirements Analysis: From Business Views to Architecture


Team-Fly

	Requirements Analysis: From Business Views to Architecture By David C. Hay
	Table of Contents

	Chapter 2. Managing Projects

Process Three: Gather Information

So, how do we go about learning about the enterprise and its requirements? The steps are:

Step 1: Conduct briefing. Introduce yourselves to the people you will be relying on for information.
Step 2A: Conduct interviews . Speak to subject-matter experts individually to learn the nature of their work.
Step 2B: Conduct "joint application development" (JAD) sessions. Alternatively, speak to people in small groups, developing models with their assistance.
Step 3: Obtain industry information and patterns. Seek out information about how other companies in this industry work. A similar project is very likely to have been done before in another company. Take advantage of that, if possible.
Step 4: Review the range of available software. At all costs you should avoid having the characteristics of available software lead your analysis, but it is sometimes possible to learn important things about the nature of the business from the design of software that has served similar functions.

The primary deliverable from this process is a set of notes and sketches , along with a log of who was seen. It also includes any supplemental industry and current systems information that might be available as well as samples of as many reports and forms as can be collected.

These steps are described further in the following sections:

Step 1: Conduct Briefing

Before imposing on the subject-matter experts' time for interviews and modeling sessions, it is polite to introduce the project to them. A one- to two- hour briefing session is an excellent way to do this. Gather together the key users identified in Process Two who will be the targets of interviews and modeling sessions. In this session, introduce:

Yourselves
The purpose and scope of the project
Your requirements on these people for time, and so on
The modeling process, with enough samples of the technique to get across what you are trying to do

The project sponsor should lead the meeting, and it is useful if one or more executives are present as well, in order to communicate the importance of the whole effort.

Step 2A: Conduct Interviews

Talk to people. Arrange to meet with each of the subject-matter experts that you have identified. Ask them what they do for a living. Do not ask them what they want from new systemsat least until the end of the interview. The idea is to get a clear picture of their activities and needs, uncorrupted by their preconceptions as to how a system would help. Have a second person present to take notes. Plan to devote a full day to each interview: the first half to conduct the interview itself, and the second half to review your notes and make them readable.

There are actually two kinds of interviews that you will conduct: A survey interview, typically with a top executive, covers general ideas and perspectives. This usually takes no more than an hour or so. You are trying to get a sense of the company's priorities, objectives, and constraints. A detailed interview with someone in the organization's operations will then take you into the nitty-gritty of exactly how a department works. Here you ask what forms and other information the person receives, what is done with them, what is produced, and to whom it is sent. This could take many hours.

Step 2B: Joint Application Development (JAD) and Feedback Sessions

A joint application development session is a meeting of a small group of subject-matter experts to examine an application area in detail. Often this involves creating one or more models of the organization in front of the experts and getting their agreement at that time. These sessions can be used either to get information initially or to get confirmation of models developed from interview notes.

Begin by choosing a subject and discussing the things of significance in that area. Follow the logic of the relationships among them to arrive at a model. If it is truly prepared jointly, all involved will take it as their own.

Note that the entity types first identified may not be the ones finally arrived at. Be alert to patterns in the model, and try to recognize cases where several entity types are really simply examples of a more general concept. Once the concept has been identified, see if there are other examples that were not initially identified.

In each case, identify the relationships between pairs of entity types and verify that they are correct: Is the name meaningful? Is the cardinality ("one and only one" or "one or more") correct? Is the optionality correct? (Must at least one occurrence of the second entity type be related to each occurrence of the first entity type?)

If you are leading a session to develop a model from scratch, construct it on a whiteboard or flip chart as the meeting goes along, based on the comments of the participants . If the session is based on a previously developed model, present it on transparencies and eagerly mark them up. Understand that the objective of the session is not only to create (or update) the model, but to do so with the maximum involvement possible by participants.

Step 3: Obtain Industry Information and Patterns

This is about two kinds of information. First there is the basic information about the industry. If you are dealing with oil exploration, you will have to learn something about geology. If you are addressing pharmaceutical clinical research, you will have to learn the vocabulary of FDA New Drug Application submissions. For cable television, you will have to learn about spots and program segments. Some of this will come from your interviews, but, where possible, it is also valuable to seek out background texts , journals, and other publications .

A more specific kind of information is about how others in the same industry are addressing the problem you are attacking. Are patterns of data or function models available? Check out industry organizations for additional information.

Your author, for example, has published a collection of generic patterns that apply to all industries [Hay, 1995]. IBM has developed specialized data models for insurance, banking, and so forth. The Petrotechnical Open Software Corporation (POSC) has developed a model of the "upstream" oil exploration and production business [POSC, 2000]. Undoubtedly others are available as well.

Step 4: Examine Current Systems

It is not a good idea to obtain requirements for new systems from existing systems. Consider that, when the existing system was built:

Someone from the business community had a set of requirements.
The analyst interpreted those requirements and transmitted that interpretation to the designer.
The designer interpreted the analyst's interpretation and passed the result to the programmer.
The programmer interpreted what the designer said and created program code accordingly .

How close to the original business community's requirements do you suppose the resulting system is? Now it's five or ten years later and you are going to try to infer current business requirements from the programmer's interpretation of the designer's interpretation of the analyst's interpretation of what was heard from the business community that long ago?

This doesn't seem like a good source of requirements.

It is, however, an excellent source of information about how the business currently operates. There are data elements captured that are probably still important. The processes may not now be the same (or be desired to be the same), but you can infer essential functions (and important business rules) from the existing processes. In these systems, you also have a lot of information about the data actually being used by the enterprise.

Most significantly, if a system is to be replaced, it is important to know all of the things it does and to know that each of these things is being replaced or is being discontinued intentionally. It is especially important to know how any replacement system will communicate with adjacent systems.

Step 5: The Deliverable

The primary result of this process is not a formal deliverable. It is a set of notes and sketches, along with a log of who was seen, plus any supplemental industry and current systems information that might be available.


Team-Fly

Top