CS 146 - Project One
Requirements Document for a
Restaurant Software System

Drake University
Spring, 2006


Due date: March 2



Project Objectives

    As you know, you are to work in small assigned teams. The primary purpose of this project is to practice and demonstrate facilitity with the requirements elicitation and analysis activities studied in Chapters 3 through 15 of "UML 2 and the Unified Process" (2nd ed.) by Arlow and Neustadt. You will do so by producing a Requirements Ananlysis Document (RAD) for a software system to be suggested (and only somewhat described) below. You do not need to incorporate everything studied in the textbook, but you should make an effort to coherently and consistantly incorporate many of the UML features into your RAD in useful ways. The next section describes briefly the intended software system and some of its functional requirements. This is not complete, and you should work to formulate a more complete set of functional requirements. You should feel free to ask me questions concerning this. As for non-functional requirements, you can produce a list of these on your own, enough to demonstrate that you put some thought into the issue. As described in the book, you should generate a "requirements model" and a "use case model," and you should relate these. You should also include a careful glossary of terms to help avoid ambiguity in your RAD. The RAD should have plenty of UML diagrams, and these should be generated using MagicDraw. Besides use case and class diagrams, you should include some activity diagrams and sort of interaction diagrams (sequence or collaboration). Besides the textbook, you should consult my on-line notes for more further information and examples.

Note: This project will provide a basis for the other two projects.


Description of the Software System

    Alice's Restaurant (feel free to change the name!) has contracted with you to develop a software system to manage various aspects of their business. The system needs to maintain dynamic awareness of customer parties (groups, not fiestas), meal orders (including take-out orders) and their statuses, reservations, menu items (incuding daily specials), recipes (including how much of each ingredient), inventory of ingredients, chef data (including specialties - used exclusively as daily specials), and work schedule for chefs, waiters and other personnel.

    The system should be able to robustly and easily add/delete/alter the elements of the system, like individual chefs, menu items, recipes, reservations, etcetera. I claim that there are implied requirements here that you should be able to gleen on your own, possibly by discussing the needs of the restaurant owner with me. However, I'm mostly thinking about "common sense" issues from the restaurant's point of view, and you should certainly make an effort to "see the world" from that point of view, so as to better anticipate their needs. Apart from the above stated and implied responsibilities, the system should be responsible for automatically updating inventories of food items (ingredients) as these are consumed in meals and as they are provided by suppliers. It should also generate a daily list (stored in a file) of total meals sold of each type. Based on these lists, it should be able to determine the weekly need for food items (ingredients), and should use this to help automate reordering from suppliers.

    The system should present different "views" (I/O interaction) to three different types of users (depending on their needs): software system manager, staff manager and waiter. You should be able to figure out which system features should be available to which type of user. Needless-to-say, the system should be as easy to use as possible, while providing all of the functionality stated or implied in the above description, plus anything else that we decide as we discuss the system, i.e. as you elicit further requirements. You are encouraged to ask questions to gain further clarity concerning functional requirements. A text-based user interface is adequate. (Later, when designing and writing code, you may opt for a GUI if you wish, but won't get credit for this.)


Organization of the Requirements Document

    The precise organization of your RAD is up to you. Remember that a non-technical client is suppose to be able to read it. However, you also want to be able to use it to initiate the design of the system, and it should include ample UML modeling diagrams. As I said earlier, and as indicated in Figure 3.3 on page 52 of your textbook, your RAD should detail the requirements and the use-cases, and you should provide some sort of list of connections between these. The document should begin with a narrative that provides an overview of the system (in more detail than I provided above). Here is a sample table of contents for a RAD that I quickly found on the internet: 

http://cs.wwc.edu/~aabyan/435/Forms/RAD.html

This should at least give you a sense of what I'm looking for, but again you are free to organize the material as you see fit.