Project Name
??/??/04,
Version major.minor
This is a requirements and specification document template for CS169. Please follow these directions for filling out this template carefully. Items in italics are information that you are to fill in, beginning with the project name, date, and version number above. See below for an explanation of version numbers. If any sections is not applicable, put N/A in the body of the section (do not delete the section). Also, if the information has already been given in another document, refer to that document.
There is no standard for requirements or specifications documents and in fact many organizations blend aspects of requirements, specification, and design in a single document. We will use a simple template for requirements and specification. Inevitably in preparing this document you will discuss design and planning, but limit this document to requirements, a description of how the system should interact with the outside world.
Each team must send a copy of this completed document to cs169@cory.eecs.berkeley.edu by 5pm on the due date. The subject line of the email message must contain only the word “proj3”.
A one paragraph summary of what the software will
do.
Document Revision History:
Your first version of this document is version 1.0. After that minor changes increment the minor version number (e.g., 1.1, 1.2, …) and major changes increment the major version number and set the minor number to zero (e.g., 2.0, 3.0, …). We will follow this convention with other documents as well.
Rev. 1.0 YYYY-MM-DD - initial version
Customer
A brief description of
the customer for this software, both in general (the population who might
eventually use such a system) and specifically for this document (the
customer(s) who informed this document). Every project is expected to find an
external customer (ie, not you). Requirements should
not be derived simply from discussion among team members. Ideally your customer should not only talk
to you about requirements but be excited later in the semester to use the
system.
Competitive
Landscape
Briefly identify the competitors in this market, this may need to be on a country and industry basis as
the landscape varies dramatically. Any functional details about the competitive
solutions should be provided. For
example the known strengths or differentiator points in the competitive
solutions, and also their weakness.
Identifying the strengths helps ensure that we design a competitive
solution; the weaknesses allow us to consider these as areas for potential
differentiation. Remember there are all sorts of sources for competitive
information -- Marketing, Development, Customers, the internet, field staff,
and those that we have hired from the competition – don’t be afraid to be
creative here. Note that this section may or may not be something that we want
customers to see, depending on how ‘honest’ of a company as which we wish to
appear.
What
product features can create competitive differentiators? Competitive
barriers? Can a patent position be obtained in this area? What is the
current patent status in this arena?
User Requirements
This section lists the behavior that the user(s)
sees. This information needs to be
presented in a logical, organized fashion.
It is most helpful if this section is organized in outline form: a
bullet list of major topics (e.g., one for each kind of user, or each major piece
of system functionality) each with some number of subtopics.
Use Cases
Use cases that support the user requirements in
the previous section. Every major
scenario should be represented by a use case, and every use case should say
something not already illustrated by the other use cases. Diagrams (such as sequence charts) are
encouraged. Ask the customer what are the most important use cases to implement
by the deadline. You can have a total ordering, or mark use cases with “must
have”, “useful”, “optional”. For each use case you may
list one or more concrete acceptance tests (concrete scenarios that the
customer will try to see if the use case is implemented).
User Interface
Requirements
Describes any customer user interface requirements including graphical
user interface requirements as well as data exchange format requirements. This also
should include necessary reporting and other forms of human readable input and
output. This should focus on how the feature or product and user interact to
create the desired workflow. Describing your intended interface as
"easy" or "intuitive" will get you nowhere unless it is accompanied by
details.
Security Requirements
Discuss
what security requirements are necessary and why. Are there privacy or
confidentiality issues? Is your system vulnerable to denial-of-service attacks?
System Requirements
List here all of the external
entities, other than users, on which your system will depend. For example, if your system interoperates
with sendmail, you will depend on apache for the web
server, or you must target both Unix and Windows, list those requirements
here. List also memory requirements,
performance/speed requirements, data capacity
requirements, if applicable.
Specification
A detailed specification of the
system. Every possible
execution should be in the specification, though not every aspect need be
covered in extraordinary depth. UML, or
other diagrams, such as finite automata, or other appropriate specification
formalisms, are encouraged over natural language..
Checklist
The
following checklist is provided to help the reviewers (and author) prepare for
the review by providing a set of questions for the reviewer to answer about the
specification document. If the answer to
any question is "no", that item should be identified as an issue at
the review. The checklist is only a
guideline; it should not be solely relied upon for a complete review. Reviewers
may want to add their own questions to the checklist.
Y N CONTENT
___ ___ Do the requirements state the customers
needs?
___ ___ Do the requirements avoid specifiying a solution?
___ ___ Do the requirements avoid specifying a
design?
___ ___ Are you satisfied with all parts of the
document?
___ ___ Do you believe all parts are possible to
implement?
___ ___ Is each part of
the document in agreement with all other parts?
COMPLETENESS
___ ___ Are the requirements properly
prioritized?
___ ___ If there are
requirements imposed by third party products, are those requirements listed?
___ ___ Are all of the necessary interfaces
specified, including input and output?
___ ___ Are the specifications precise enough?
___ ___ Are all performance requirements (e.g.
speed, memory, capacity) specified?
___ ___ Where
information isn't available before review, are the areas of incompleteness
specified?
___ ___ Are all sections from the document
template included? If not, is there reason for the changes?
CLARITY
___ ___ Are all requirements reasonable?
___ ___ Is the level of
detail of each requirement appropriate?
___ ___ Are the requirements written in a
language appropriate to the audience?
___ ___ Are all items clear and not ambiguous? (Minor
document readability issues should be
handled
off-line, not in the review, e.g. spelling, grammar, and organization).