CS 130: Software Engineering, Spring 2009: Project Assignment 1

Project Name

Requirements and Specification Document
??/??/??, Version major.minor

This is a requirements and specification document template for CS130. Please follow these directions for filling out this template carefully. You are to fill in the various subsections in this document, 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.

We expect you to write this document in stages. Try to meet as soon as possible and write the outline requirements and specification. Use this as the basis for your presentation on Wednesday. Incorporate the feedback from your presentation, as well as results of further meetings, into the submitted version. After submission, as the quarter progresses, update the document as needed, using the revision history to keep a record of what changed. The final document will be part of your project submission.

One suggestion is to organize your project repository into a src directory for source code and a doc directory for project related documentations. Keep the documents also in your repository for easy sharing.

How to submit: We are setting up courseweb to accept this document. Each team must upload one copy of the completed document to courseweb by 11:59a.m. on April 20, 2009.

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, etc) and major changes increment the major version number and set the minor number to zero (e.g., 2.0, 3.0, etc). We will follow this convention with other documents as well. Additionally, put in a short comment about the major change in the document since the last revision.

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 (i.e., 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 quarter 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 use case diagrams and 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.