Project Specification

This is the specification of the project, which sets out what you are supposed to deliver and when. It is a mini version of real commercial project, following some fairly standard method. Note that the point of the project is not to teach you some particular development methodology. The below process is basically a minimal skeleton for how a larger project gets developed.

Overall, the idea of the project is the following:

• You are given the requirements specification, a document that describes what you are supposed to implement in the project.
• You are also given a host of other information, hints, and tips, that will help you achieve the goals listed in the requirements specification.
• In your turn, you are supposed to deliver three deliverables to the project staff:
  1. A system description that is your interpretation of the requirements.
  2. An architecture sketch that explains the basic structure of your operating system.
  3. A system design that forms the basis for your implementation work.
  4. A final deliverable, which is the actual operating system and its documentation.

The time plan for these delivirables is given on the main project page

Below, all of these documents are explained.

The requirements are set up by your customer (the teachers in the project in this particular case), and you have to fulfill them. The requirements specification details what you are supposed to be implementing. Consider it as an order that you have obtained from a paying customer. In exchange for implementing the system described in the requirements specification, you will obtain some kind of compensation. In this particular case, the compensation is given in the currency known as passing grades :).

The requirements specification should not specify the particulars of how you implement your system; each group is allowed lots of freedom in how they meet the various requirements. There is no "right" way: any way is good, as long as the requirements are fulfilled.

The requirements are divided into mandatory and extra credit requirements. All groups have to fulfill all mandatory requirements. However, if you fulfill one or more extra credit requirements, your group have the potential to raise your exam grades. And have lots of fun and learn even more.

Describes the requirements as interpreted by you, and will function as a contract for the final delivery. The purpose is to make sure you understand the problem before you start working on the architecture.

The architecture sketch should describe the structure of your operating system (which modules does it decompose into), and ideas of the data and control flow for major operations (like the delivery of messages between processes, or the initialization of the system).

The architecture sketch should be written before you start doing any coding!

The purpose of having you write this document is twofold: first, it will help you get started in thinking about how you want to do things. Second, it will let the teachers provide feedback to keep you on the right track, and detect if any group is getting lost.

Given your architecture sketch, you will then move on to produce a system design. This document is going to be your main guide when you do your actual implementation as program code.

The system design will describe the actual format and parameters for all system calls, both those exposed to user programs, and those used between modules in your operating system. It will define all datastructures needed for communication between modules, as well as the most important internal data structures. If any non-trivial algorithms are needed to implement the operating system, they need to be described here.

The detail level of the system design should be such that a programmer can write the code for a particular module of your operating system only by referring to the system design, and not to his/her fellow programmers.

At this level of detail, you are very much describing the how of your operating system. The system design details just how you will solve all the requirements of the requirements specification. This is where the real work of producing a working system is done; the writing of the code that follows the system design is not the core task. The key task in programming is the design, not the actual production of code following this design.

Finally, the system design should contain an implementation schedule for your operating system. This should lay out in what order and approximately in which time frame the parts of the operating system are to be implemented.

The final deliverable you are to provide will contain:

• The actual operating system code & executable.
• Instructions for how to start & test the operating system.
• A programmer's guide to the OS API.
• A user's guide for the programs you provide.
• A checklist where you indicate the requirements you have fulfilled and a brief note for each how you fulfilled it.

See the final deliverable page for more details on the documentation requirements.