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.
Your requirements specification document should have the following
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.
Prepare a 15 minute presentation, after which we will
allow some time for questions. Prepare your presentation
appropriately. Your presentation should include
Overview of your system;
Environment and interfaces;
Highlights of your requirements specification including
Summary of required capabilities, with a diagram if
one or more detailed requirements for the most important capabilities
(pick the key issues to discuss in detail);
Lifecycle considerations (how you intend to develop the
system throughout the lifecycle);
System test plan
Current state of your project plan;
how you intend to both demonstrate that the system should be accepted
as well as how you intend to convince yourselves that it is more than
Be sure to focus your presentation on the key issues.
spend time with the obvious things. If there's something in your
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
project assignments are extensively borrowed from Professor Richard
Taylor's website at UCI.