Summary

   

---

Defining the Mission Objectives

To expand upon the overview in the previous chapter, mission objectives are statements that represent the general tasks supported by the data maintained in the database. Each mission objective represents a single task. These mission objectives provide information that you'll use throughout the database-design process. For example, mission objectives help you define table structures, field specifications, relationship characteristics, and views. They also help you establish data integrity and define business rules. Finally, mission objectives guide your development efforts and ensure that your final database structure supports the mission statement.

Well-Written Mission Objectives

A well-written mission objective is a declarative sentence that clearly defines a general task and is free from unnecessary details. It is expressed in general terms, succinct and to the point, and unambiguous. Here are some examples of typical mission objectives:

We need to maintain complete patient address information.

We need to keep track of all customer sales.

We need to make sure an account representative is responsible for no more than 20 accounts at any given time.

We need to keep track of vehicle maintenance.

We need to produce employee phone directories.

These mission objectives are well defined and easy to understand. Each mission objective represents a single general task and defines the task clearly without unnecessary details. For example, the last mission objective in the list states that employee directories need to be produced, but it doesn't indicate how they are to be produced. It is not necessary to indicate how the employee lists will be produced because that issue is part of the application-development process. Remember that the purpose of a mission objective is to help define various structures within the database and to help guide the overall direction of the database's development.

If a mission objective represents more than one general task, you should decompose it into two or more mission objectives. Here is an example of a poorly written mission objective:

We need to keep track of the entertainers we represent and the type of entertainment they provide, as well as the engagements that we book for them.

There are two problems with this mission objective:

1. It defines more than a single general task. It is clear that there are two tasks represented in this statement: keeping track of entertainers and keeping track of engagements.

2. It contains unnecessary detail. It's unnecessary to refer to the entertainer's "type of entertainment" in this mission objective. The phrase "type of entertainment" either refers to a distinct characteristic of an entertainer, or it represents a new task that should be declared as a mission objective. If it refers to a distinct characteristic of an entertainer, it should be removed from the statement; otherwise , it should be used as the basis for a new mission objective.

You can fix this mission objective by removing the unnecessary detail and rewriting it as two mission objectives. (Keep the details you discard on a separate piece of paper; they may be useful later in the design process.) Here is an example of one possible revision:

We need to maintain complete entertainer information.

We need to keep track of all the engagements we book.

Notice that each mission objective now clearly defines a single general task and is easy to understand as well. Mission objectives such as these are easy to use as you design the database.

Composing Mission Objectives

Defining mission objectives is a process that involves conducting interviews with users and management and then writing appropriate mission objectives based on the information gathered from the interviews.

The purpose of the interview is to determine what types of general tasks need to be supported by the data in the database. You accomplish this by asking the participants open -ended questions and allowing them to elaborate on their replies as necessary. The mission statement and mission objectives interviews are the easiest ones you'll conduct during the design process because everyone is usually enthusiastic about participating. It's fairly easy to get people to discuss what they do on a daily basis and to give their perspective on the function of the organization. This is also one of the few interviews you'll conduct with both users and management; there should be a lot of common ground between the two groups due to the general nature of the interview.

One very important point to remember is that the interviews you conduct here involve very general discussions . The discussions are more conceptual than analytical; your intent here is not to analyze the current database or database application, but to get an overall idea of the general tasks the database should support. Keep in mind that one of the purposes of the mission objectives is to help guide the development of the database structure.

As you conduct the interview, be sure, once again, to ask open-ended questions. Remember that open-ended questions are apt to elicit better responses from your participants. Ask the participants questions regarding their daily work, how the organization functions, and what type of issues they believe need to be addressed by the database. Encourage them to discuss as many facets of their work and the organization as they possibly can. As they reply, try to record each response as a declarative sentence. You'll find it is much easier to transform a sentence into a mission objective if you can do this. Here are just a few examples of the types of questions you could pose during the interview:

What kind of work do you perform on a daily basis?

How would you define your job description?

What kind of data do you work with?

What types of reports do you generate?

What types of things do you keep track of ?

What types of services does your organization provide?

How would you describe the type of work you do?

All of these questions are likely to evoke a good, lengthy response from the participant. One of the advantages of questions like these is that they provide the opportunity for you to ask follow-up questions. For example, say you received the following response to the last question in the list:

"First, I try to determine the general problem with the vehicle. Then I fill out a work order and note my assessment of the problem. Finally, I send the vehicle to the next available service team."

You'll immediately notice that it's a lengthy response, which is fine. You should also note that you could easily ask a follow-up question, such as the following:

"Is there any type of customer information incorporated within the procedure you just described?"

Even if the reply is no, the question is still open-ended enough for the participant to elaborate further on his original response. This type of follow-up question could also jar his memory and cause him to relay other information, which may be related to the subject of the original response.

Here is a set of mission objectives that you could derive from the participant's original response:

We need to maintain information on customer vehicles.

We need to keep track of work orders.

We need to maintain information on our service teams .

We need to maintain information on our mechanics.

We need to maintain information on our customers.

Three of these objectives are derived directly from the response. They're easy for you to determine because their subjects are explicitly stated in the response itself. The last two mission objectives are derived from assumptions based on the response. This is a technique (which you can think of as "reading between the lines") that experienced database designers use quite often, and it is one that you should use when you're defining mission objectives. The technique relies on your ability to determine what information a response conveys implicitly , as well as what it conveys explicitly . So pay attention. Listen for implications. Without good assumptions, your overall set of mission objectives could be incomplete.

Review the following response and determine whether there is implicit information hidden within the response itself:

"I book entertainment for our clientele, which consists of commercial and noncommercial clients. Our noncommercial clients are typically individuals or small groups who book weddings, birthdays, anniversaries, and the like. Our commercial clients , on the other hand, consist of businesses, such as nightclubs and corporations. The nightclubs book entertainment in six-week slots; the corporations book things, such as corporate parties, product rollouts, and various types of promotional functions."

Aside from the explicit information that this response conveys, there are at least two pieces of implicit information that you can uncover in this response. The first piece of implicit information concerns the need to maintain information on the entertainers booked for the engagements. An agent needs to know things such as the entertainer's name , phone number, mailing address, availability, and whether he will travel to out-of-town locations. The second piece of implicit information concerns the need to maintain information on the engagements themselves . An agent must know all the details concerning the engagement in order to ensure that the engagement runs smoothly.

Now that you know how important it is to look for implicit information, keep it in mind when you're defining mission objectives.

Here are the "final words" regarding mission objectives: Make sure that your mission objectives are both properly defined and well defined, that each objective makes sense to you and to those for whom you are designing the database, and that you look for any implicit information hidden within every participant's response.

CASE STUDY

It's time now to interview Mike and his staff so that they can help you define the mission objectives for the Mike's Bikes database. Here's a partial transcript of the interview with Mike. Once again, your assistant, Zachary, is conducting the interview.

Z ACHARY:	"Can you give me an idea of the things you'd like to track in the database?"
M IKE:	"Oh sure, that's pretty easy. I want to keep track of our inventory, our customers, and our sales."
Z ACHARY:	"Is there anything else that you can think of that is related to these subjects?"
M IKE	"Well, I guess if we're going to keep track of our inventory, we should know who our suppliers are."
Z ACHARY:	"What about the sales reps involved in each sale?"
M IKE:	"Oh yeah, we should definitely keep information about our employees . If nothing else, it's a good idea to do this from a human-resources point of view. At least, that's what my wife tells me!"
(The interview continues until Zachary has finished asking all the questions on his list.)

When the interviews are complete, review all the information you've gathered and define the appropriate mission objectives. Be sure to keep the "final words" in mind as you define them. Here are a few possible mission objectives for the Mike's Bikes database.

We need to maintain complete inventory information.

We need to maintain complete customer information.

We need to track all customer sales.

We need to maintain complete supplier information.

We need to maintain complete employee information.

Once you've compiled a list of mission objectives, review them with Mike and his staff. When they are satisfied that they understand the mission objectives and that the list is relatively complete, commit the list to a document in your favorite word processor and save it for later use.

---

Top