Section 1: Problem Description and Functional Requirements

 

These two stages represent everything that must be done before starting with the different stages in the database design methodology covered in the course. No particular analysis methodology has been covered here, and as this is an exercise we have no real customers for you to practice on. But this stage is too important for you to ignore completely.

 

1a: Problem Description:

This section should only be a page or two. Write a high level description of the organization you are dealing with. Include

*      The purpose of this organization (“Wonder Airlines is a small regional airline…)

*      The different people and things involved in it (“The airline flies a fleet of 25 small and medium planes, serving a total of…”)

*      Why a database is needed (“Following rapid growth, the airline is having difficulty in tracking the flying habits of its frequent fliers…”)

*      What the database would include (“The database must track

*      Who would use the database (“The new database would be used by ticket reservation clerks, check-in staff, personnel managers and other managers…)

Write in clear English paragraphs. You should include several sentences for each point ahead. Structuring is up to you, but you may wish to have a paragraph for each one.

 

It’s fine to mention some things here (say plane maintenance) and say that they fall outside the scope of the current exercise.

 

1b: Functional requirements

 

For clarity, I suggest that you use bullet points for this section. This will run to several pages, and should be as complete as possible. Include the following three KINDS of item here. You will want to have several examples of each type.

 

*      THINGS THE SYSTEM WILL HAVE TO DO: List a number of these. With these, you’re not talking explicitly about what data it has to store – you’re talking about what it has to output. Pretend that you are actually building one or more applications to go with the database. For example, “The system must let managers produce reports showing how many minutes early or late each flight was during a particular day. It must also allow the production of aggregate totals showing on-time performance for all flights in a particular month.” 

*      PIECES OF INFORMATION THE SYSTEM MUST STORE: These are all the things that will have to show as attributes somewhere in the ERM. One way to get them may be to take the requirements mentioned above and figure out what pieces of information will be needed to support each of them.

*      FACTS ABOUT THE ENTITIES AND ATTRIBUTES: You should get more detailed here than in the overall problem description. For example, although in the problem description you might mention that the airline has pilots and flight attendants, it is here that you would mention that pilots need to be periodically certified. Also include here information about relationships – for example that pilots fly planes or that a flight number will leave at the same time every day.

*      ASSUMPTIONS ABOUT THE WORLD. Making assumptions explicit is always good practice in a real project. It is particularly important here because I will be looking at the assumptions and comparing them to the ERM. Assumptions may include things like “each customer will have only one address at a time”, or “each cruise booking will only ever include a single cabin”  or “a waitress always works for an entire eight hour shift” or “a pilot will always fly the same plane.”

*      ASSUMPTIONS ABOUT THE SYSTEM. Unlike the assumptions mentioned above, there are assumptions about acceptable behavior of the system. Use these to simplify your task and make it manageable. These assumptions include, but are not limited to, definitions of the systems scope. For example: “the system will not store old addresses. When somebody changes his or her address, the old value will be overwritten.” That’s not an assumption about addresses themselves, but on what is acceptable for the system.

 

As you work more on the ERM you will make (or discover) further assumptions and may reduce the scope of the system.

 

You are not required to use any particular methodology. If you are already skilled in a particular methodology then feel free to use it. If not then I suggest you use each of the headings shown above as the title of a section. However, all the above areas must be covered. It is up to you whether to split your report up into the five areas I use, what order to cover each area in, and so on. Just make sure that you are thorough. Please number each of your items. This will make it easier for you to refer back to them later – for example in pointing out that one of the queries you implement will support requirement B-19 or that requirements B12-B15 have not been selected for implementation.

 

Here are a couple of hints for this part of the project.

  1. Actually try and find out something about the real-life system you are modeling. As part of the project selection form you listed real information sources. Use them – you will get more credit.
  2. Relate your functional requirements to this information. Quote from it, attach it as an appendix, or even footnote it. Show that you have thought it through.
  3. It’s fine to simplify. In fact you won’t be able to get the exercise done unless you do. But please, list all your simplifications and assumptions explicitly.
  4. Make sure that you keep your requirements consistent with your ERM. If you make changes to the ERM then update the requirements. If you realize that your ERM includes particular assumptions that you did not make explicit then go back and make them explicit. You ERM will be judged in large part on how well it mirrors your requirements – not directly on how much like the real world it might be.