Project Requirements and Specification
(Borrowed and Adapted from UCB CS169)
Your Project Name
Requirements and Specification Document
??/??/????, version major.minor
Instructions
This is a requirements and specification document template for Software Development Principles and Practices. Please follow these directions for filling out this template. 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.
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.
This will be a living document. For the first sprint you will fill in the overview sections (Abstract, Customer, Competitive Landscape), and a few of the requirements that you plan to implement in the first sprint. In subsequent sprints you will expand the applicable sections.
You have to use the Github wiki of your private team repo.
Submission
You must send an email to [email protected] with a PDF version of your document.
You must send the email by the deadline in the class calendar. This is a HARD deadline.
Project Abstract
A one paragraph summary (about 200 words) of what the software will do. (Must include in the first version.)
Document Revision History
Your first version of this document is version 1.0. When you evolve this document for future sprints of your project you will increment the minor version number (e.g., 1.1, 1.2, ...). We do not expect that you will have to increment the major version number in the course of this semester. For every version after the initial version, you should list a short bullet list with the main changes and extensions that you made to the document:
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). (Must include in the first version)
Competitive Landscape
Briefly identify the competitors in this market, and list the main ways in which your project is going to be different.
(Must include in the first version)
User Stories
This section will include the specification for your project in the form of user stories. For each user story, you should have at least a Feature and one or more Scenarios, each of which can have one or more Acceptance Tests. Acceptance Tests list one or more acceptance tests with concrete values for the parameters, and concrete assertions that you will make to verify the postconditions. Each user story should also have a field called "Sprint" where you specify in which sprint you implemented or plan to implement this feature.
You should list only the user stories for the previous sprints and those for the current sprint.
At the end of this section you should maintain a bullet list of user stories that you plan to get to in future sprints, with only minimal detail for each such story. We expect that in future sprints some of these items will be promoted to full fledged user stories. (Must include in the first version, and must be expanded for future sprints)
User Interface Requirements
Describes any customer user interface requirements including graphical user interface requirements. Here you should have sketches or mockups for the main parts of the interface. To save time you may want to use scanned drawings of interface mockups here, instead of Photoshop drawings.
Just like for the User Stories section, you need to list here only the parts of the user interface that are applicable to the previous sprints and the current one. (Must include in the first version, and must be expanded for future sprints)
Requirements grading guidelines:
These are the grading guidelines that staff will use to evaluate your document.
| Max Points | Content |
|---|---|
| 5 | Do the requirements state the customers needs? |
| 5 | Competitive analysis |
| 5 | Do the requirements avoid specifying a design (customer-specified design elements are allowed) ? |
| 5 | Do you believe all parts are possible to implement? |
| 5 | Is the project scope big enough? |
| Completeness | |
| 20 | Are the user stories written in sufficient detail to allow for design and planning? |
| 5 | Do the user stories have acceptance tests ? |
| 5 | Do the user stories mention error conditions and required behavior ? |
| 5 | Are there sufficient user stories for the first iteration? |
| 5 | Is there a discussion of the stories for future iterations ? |
| 20 | Are the User Interface Requirements given with some detail? Are there some sketches, mockups? |
| Clarity | |
| 5 | Is the document carefully written, without typos and grammatical errors? |
| 5 | Is each part of the document in agreement with all other parts? |
| 5 | 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). |