Home Schedule Course Policy Assignments Project

The Concept:

During this project you will select and describe an organization in need of help. Then you will propose and describe an information system you think would meet it needs, then run through the different phases of the system development life cycle as studied during the course. This will run from the initial feasibility study and systems planning phase through the systems analysis phase and the systems design phase. You will not be required to do any actual implementation, but you will need to come up with a plan for the systems implementation and systems operation and support phases.

Resources for the Project

There is a hints page for the project, with specific guidance on each deliverable. Click here to read it.

You may wish to use Microsoft Visio to tackle some of the assignments, particularly to prepare data flow diagrams, entity relationship diagrams, and system architecture diagrams. I have prepared a sample Visio page holding the shapes you will need. Download it here.

I have two sample projects from students who received A grades on them. Note that some of the guidance and details have changed since then -- I have tried to note the paces where expectations are now different.

Newer example project: Victory Garden Initiative

  • Sample Phase I for Victory Garden
  • Sample Phase II for Victory Garden (NOTE:  you should evaluate two packages -- changed from one in this example)
  • Sample Phase III for Victory Garden (NOTE: the screens are a little unimaginative in comparison to the rest of the project, as one is a user registration screen and one is a generic email and password screen. Don't copy these!)
  • Sample Phase IV for Victory Garden
  • Sample Phase V for Victory Garden

Older example project: Lancon d.o.o. (English School)

  • Sample Phase I for Lancon (NOTE: the instructions for the feasibility section have changed)
  • Sample Phase II for Lancon
  • Sample Phase III for Lancon
  • Sample Phase IV and V for Lancon (NOTE: this does NOT include the effectiveness metrics)

Grading forms

Look over these before submitting your drafts, to make sure that you have covered all the required items.

Selecting Your Project:

The organization you use for your project on should be real, or based on a real one, and it will usually help if you pick one you know something about and have some interest in. However, you do NOT have to remain entirely true to reality. If the real-life version of the organization is too small to need a computer system, you can pretend that it has expanded to five stores instead of one and is having difficulty with its old methods. Don't bite off more than you can chew -- trying to do the whole of a huge company like Wal-Mart or Ebay would be too hard. If the real life version is too big to work with, for example the PetCo chain, then you could pretend that the branch of it you are studying is a single, independent pet store in need of a system to track its products and customers. Do not be scared to make up plausible seeming details in Phase I.


  • In a library: A computerized system to track the catalog of books, tapes and other materials, together with the library patrons and their borrowing activity.
  • In a restaurant: A computerized system to track reservations, assign seats to patrons, track food and beverage orders and produce bills. It might also offer a "frequent diner" program.

If you have a job or internship, there will almost certainly be some kind of real or hypothetical information system to study.  It may be that the organization you are familiar with already has some kind of computer system. In this case you have a choice. You could take yourself back in time and pretend it didn't yet exist, so that you can design another system to do the same basic job. That's OK as long as you don't just totally copy the real system. Or, you could admit that it exists and either design a replacement or a new system to work along side it. The situation you describe in your project doesn't have to totally match reality, and in fact you will probably want to simplify in some areas. But it does have to be consistent through all the phases -- the system you design in phases II and III has to fit the organization and requirements you describe in Phase I.

As you continue to work on later phases, you may discover problems or omissions in your original analysis. For example, missing processes, outputs or users. In this case, you will want to go back and revise the earlier stages before submitting the final version. Due dates for each phase are shown on the Schedule page.

Breakdown of Credit

Phase Total Credit Credit for Draft Credit for Final
I 15% 10% 5%
II 35% 15% 20%
III 30% 15% 15%
IV 10% N/A 10%
V 10% N/A 10%

If group members do not agree that an even distribution of credit accurately reflects the balance of effort within the group then credit will be redistributed between individuals following the process described in the course policy.

What to Produce

The term project requires you to supply the same kinds of reports and diagrams you have been practicing with the weekly assignments.

More details on most of these items are available on the project hints page. This gives you a good idea of how to approach the harder parts of the exercise and what I will be looking for when I grade them. Please read this carefully.

Phase I: Systems Planning (grading key for phase I)

  •  Organizational Background: Begin with a summary of the organization you are using for your example. Discuss its origins, current operations, future plans, strengths and weaknesses in a similar format to that used in the case studies in Chapter I of the textbook. It's important to get a sense for what the major activities of the organization are and who is carrying them out.
  •  Mission Statement: Write a mission statement for the organization. This can be fairly short (one or two paragraphs). Avoid making it too specific or short term, but also try not to make it some totally general thing that could fit any organization.
  •  SWOT Analysis: Carry out an analysis of the Strengths, Weaknesses, Opportunities and Threats for the organization as a whole (not, as in the textbook example, just for the IT part of it). List at least three things in each category.

(The three items above give the background against which your proposed system will be judged, so don't be afraid to present them in such a way as to make your system seem like a really good idea, even if this means modifying or simplifying reality.)

  •  Proposed System: Give a short (one paragraph) description of the purpose of the proposed system, including the main tasks it will carry out. Don't go into too much detail here, but it is vital to have a reasonably clear idea of what the system will or will not include before moving on.
  •  Reasons for the Project (Business Case): Identify at least six different potential organizational benefits of the project, including at least one from each from the categories given on pages 54-56 of the textbook as "main reasons for systems projects."). Spend a couple of sentences of each, and explain what they mean in the specific context of this system and this organization. It should be clear from each one how it will help the organization achieve its mission.
  •  Feasibility of the Project: Identify and evaluate threats to the feasibility of the proposed project, being sure to cover at least one threat in each of the four categories (economic, operational, technical and schedule) given on pages 61-64.
    For each of the threats you identified, give two specific things you would do to gather the additional data needed to determine whether the threat can be overcome (see the discussion preliminary interviews and data collection on page 71-2 for some inspiration -- answers might include questions you'd ask to specific people, documents you'd try to get hold of, etc).
  •  System Constraints: Identify at least ten constraints on the project, including a mix of external and internal, and of present and future. For each constraint, say where it falls on the dimensions covered on pages 69-70: mandatory/desirable, internal/external and present/future. Look carefully at the hints for this one -- the text book doesn't do a good job of explaining the constraint concept and a lot of people get confused and do a bad job on this section. Make sure your constraints are really constraints and not just design choices made by the project team.

Phase II: Systems Analysis (grading key for phase II)

We'll assume that the proposal presented in Phase I has been accepted by the organization, and you are moving forward with the detailed design and analysis for the system you proposed.

  •  System Requirements Checklist: Use the categories of Outputs, Inputs, Processes, Performance and Controls given on pages 100-101 to identify at least thirty requirements for the system. Try to make this list as complete as you possibly can. (Note, the textbook glosses over this in a couple of pages, but it is actually the most important part of systems analysis).
  •  Analysis of Users: Identify at least four distinct groups of system users. For each group, discuss their main interactions with the system. Include a list of inputs, outputs, and responsibilities for each group. Make sure that the inputs and outputs you mention fit with the System Requirements Checklist.
  •  Fact Finding Plan: Outline a plan by which you would investigate the system requirements. Include discussion of the documents you would seek to collect, and what you would hope to learn from each. Include a paragraph on each of the interviews you would conduct, and what you would try to learn from it. Inclusion of a questionnaire is optional.
  •  Data Flow Diagrams: Prepare a Context DFD, a Level 0 DFD and at least two Level 1 DFDs (pick the most complex processes).
  •  Process Descriptions: Produce a reasonably detailed, one paragraph plain English description of what each of the top level processes does (the ones in the Level 0 DFD). Then do the same for each of the lower level processes on the Level 1 DFDs. Make sure that these descriptions are arranged to give a good sense of how the system as a whole does its work.
  •  Development Strategies -- Software Acquisition: Do a real life web search, and identify two real-life packages suitable for this application. Summarize the system requirements you identified earlier and identify how well each package would meet each of your key requirements. Consider other strengths and weaknesses of each package for the organization. In doing so, consider how well each package would fit with the existing IT infrastructure and personnel of the organization, and what would need to be added in terms of people or technology to support it. Many points will remain ambiguous, so prepare a list of questions you would ask the sales representative for the company supplying the software.

When you submit the draft of Phase II, you MUST submit the graded copy of Phase I so I can see how the two relate.

Phase III: Systems Design (grading key for phase III)

Note: Phase III requires you to do your own original design work. If the sensible thing for you organization would be to do with a package then just ignore the fact for this phase, and pretend you are designing one yourself to meet the requirements.

  •  Entity Relationship Diagram: Draw an ERD for the entire system. Show relationships and cardinality (for cardinality, if you use the 1, M, N notation rather than the crow's feet one, be sure to use the format "1..M", "0..1" etc. as explained in class to show if the relationship has to include at least one record).  
  •  Data Design: For each of the entities shown on your ERD, prepare a set of data dictionary entries. These would be used to prepare data base tables to store this data. Each one of these entities will have multiple fields. For example, in many systems a "Customer" entity might have fields including FirstName, LastName, CustomerNumber and PhoneNumber. In the data dictionary entry for each of these fields, specify its name, type, length/range and source. (This is similar, but not quite the same, as the data element documentation discussed on pages 168-169). Use the same format as the exercise here. Remember you will need a separate table for each and every entity in the ERD.
  •  User Interface Design: Design at least three sample screens for the system. One of these should be a main menu screen for the application, giving top-level options for the system. One of the other screens should allow data entry. Accompany the screens with a discussion of the features used to reduce input errors and improve productivity as presented in the textbook on pages 304-321 (things like checks of different kinds, navigation features and so on). Many applications, including Access, Word, Excel and FrontPage can be used to produce screen designs.
  •  Report Design: Produce one example report from the system, including fake but plausible looking output data. Use as many of the report features discussed in the textbook as possible (groups, headers, totals and subtotals, etc).
  •  System Architecture: Devise a suitable architecture for the system. This will involve making decisions about application platforms and the use of web technologies. Justify your choices by writing a one page description of the system architecture and explaining how you made your decisions. Prepare a diagram showing the overall technical structure of the system, including users, client computers (whether fat or thin) and any required file servers, database servers, application servers, specialized hardware stations (such as card swipers or checkouts) and network connections. An example diagram is available in Visio format and as a .pdf file -- see the hints page for more details.

PLAGIARISM REMINDER:  Many people choose to design systems for real-life organizations similar to those they have personal experience with. This is good. Some people choose to design systems to do similar work to those that actually exist in these organizations. This is OK, but make sure that your system is significantly different in some way. Copying actual screen or report designs, however, is plagiarism and means that you fail the entire course. Don't make me do it.

When you submit the draft of Phase III, you MUST submit the graded copies of Phase I and II so I can see how they all relate.

Phase IV: Systems Implementation

  •  Implementation Plan: Develop a plan for the implementation phase, including programming, testing, documentation, training, data conversion and changeover strategy. Include at least a paragraph on each, with an estimate of the person-days required and who would be responsible for carrying it out. Produce a timeline showing start and end dates for each activity.

Phase V: Systems Operation and Support

  •  Maintenance Plan: Identify a plan for dealing with maintenance issues. Include some discussion of each of the four kinds of maintenance tasks discussed on page 512-514 (Corrective, Adaptive, Perfective, Preventative) and give at least one example of each kind of task in the context of this system, how it would be resolved, and who would be responsible for it.
  •  Phased Enhancements: The textbook doesn't talk much about this, but no system is ever complete in its first version (or ever, really). Identify at least three major enhancements that could be made to the system over the weeks or months ahead, and write a paragraph or more on each.
  •  Effectiveness Metrics: Back in Phase I you listed a number of organizational benefits you thought would come from the project (aka as "reasons for the project). Assuming the system is now in place, explain how you would come up with a numerical measure of how effective it had been at achieving one of them (you pick which one). This will involve comparing "before" and "after" values for this metric to see if the system has altered in in the desired manner.

When you submit the final version of the whole project, you MUST submit the graded copy of Phase I, II and III so I can see how well you have addressed the issues I raised in grading the drafts.

Page copyright Thomas Haigh -- email    Home: