CS130 Project, Part 1

(updated 9/9/2003)

Requirements Specification

Due Thursday, September 25, 2003

The purpose of this first major deliverable is to explicitly identify what the finished software product will do.  As discussed in class, we are combining the requirements phase and the specification phase into a systems analysis phase.  The end result will be the contract between your group and your client.  It will be the standard by which your project will be evaluated at the end of the integration phase and again at the end of the semester.  Do not include any implementation-specific details in your Requirements Specification.  Make sure the document is not ambiguous, incomplete, or contradictory.

Deliverable 1
Your requirements specification document should have the following contents:

Title page
Table of Contents
1. Introduction: What is the document about? Who was it created for? Who created it?
2. Application Context: A short introduction to the problem domain that your project addresses.  Describe the situation in which the software will be used and describe how that situation will change as a result of the introduction of your software.  Identify all the things that the system may or will affect (objects, processes, other software, hardware, people).  Develop an abstraction for each of those things, characterizing their properties or behavior as they are relevant to your project.  How might the application context change in the future?
3. Functional Requirements: Indentify all concepts, functions, features and information that the system provides to its users.  Provide an abstraction for each of those concepts, characterizing their properties and functions that are relevant to the user.  What is the system supposed to do?  What information does the system need?  What is supposed to happen when something goes wrong?
4. Environmental Requirements: What are the platforms, both hardware and software, on which the project will operate?  What programming language(s) will be used?
5. Potential Risks: Determine the factors that increase the occurrence of risk faced by the project.
6. Future Changes: Determine the changes that the software will undergo in the future, including potential future enhancements.
7. Acceptance Test Plan:  Describe the types of tests that will be conducted during validation and describe the format of the test cases.
8. Definitions of Terminology:  Define any special terms that are used throughout the document.
9. Reference Documents: Include references or pointers to relevant literature and tools, as well as to other similar software products.

Be concise but do not leave out anything important. 

Submission Instructions
Turn in one printed copy of your Requirements Specification.  Be sure to archive a copy for your team's records.  This will be a permanent part of the project product.  The document should have a separate title page with the name of your project, course number and title, project members, semester and year, and the calendar date submitted.  The rest of the document should start on the second page; it should be printed in 12pt font with 1.5" margins on left and right and 1" margins top and bottom.  Page numbers, document, and date should be printed on each page in a footer.  Section heading should be in bold, etc.  Staple the document once in the upper left hand corner; do not use binders or plastic covers.

Presentation Instructions
Prepare a 15 minute presentation, after which we will allow some time for questions.  Prepare your presentation appropriately. Your presentation should include the following:

Be sure to focus your presentation on the key issues. Don't spend time with the obvious things. If there's something in your presentation that you find boring, so will your audience. Don't gloss over problems. We want you to succeed but cannot help unless you explain where you think the problems are, or are likely to be.

Acknowledgement:  The project assignments are extensively borrowed from Professor Richard Taylor's website at UCI.