User Requirements Specification Template
This document is also known as Requirements Analysis Document (RAD).
I. Report Format
The report must contain the following section. Each section should be clearly delineated, with its own heading and pagination. The sections should be numbered as below, to facilitate the grading process.
A. Cover Page and Individual Contributions Breakdown, as specified in Report Preparation Section.
The contributions breakdown must contain the responsibility matrix and responsibility allocation chart as described in part II below.
B. Table of Contents
Make sure that the page numbers listed here are correct.
C. Customer Statement of Requirements
This could be a minimum of 2-paragraph high-level narrative about the project which could be copied from your project proposal, revised and improved as necessary. This should describe informally the motivation for your project, what kind of problem you are solving, and how this problem is solved in the current practice (before your proposed project gets deployed) or what amusement are you creating and how will it be appealing in the market without the use-case jargon. Use the application domain language and terminology, i.e., the language familiar to your target users, and avoid technical jargon. Utilize charts, illustrations, and screen mock-ups to make it easier for the reader to understand the problem. Provide references (books, papers, websites) where to find more information or see existing solutions. Enumerate all the requirements at the end of this section. Each requirement should briefly state what the user should be able to do using the project or what entertainment would it contribute to determine market share.
D. Glossary of Terms
List important terms and their definitions to ensure consistency and avoid ambiguity in the project specification. Use the language of the application domain and avoid uncommon terms or define these as well.
E. Functional Requirements Specification
Identify anyone and everyone who has interest in this project (users, managers, sponsors, etc.). b. Actors and Goals
Identify who will directly interact with the project, their types (initiating vs. participating) and the goals of the initiating actors. c. Use Cases
i. Casual Description
For all use cases that you plan to have in the final product, write a brief or casual text description. ii. Fully-Dressed Description
Select a few most important use cases (those that you plan to have implemented by the time of the first demo) and provide fully dressed description.
iii. Use Case Diagram
Draw the use case diagram with all the use cases.
d. Project Sequence Diagrams
Draw the project sequence diagrams for the few most important use cases selected above
F. Nonfunctional Requirements
List and describe the FURPS+ requirements.
FURPS is an acronym representing a model for classifying software quality attributes (functional & non-functional requirements):
• Functionality - Feature set, Capabilities, Generality, Security • Usability - Human factors, Aesthetics, Consistency, Documentation • Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure • Performance - Speed, Efficiency, Resource consumption, Throughput, Response time • Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability. (http://en.wikipedia.org/wiki/FURPS)
The model, developed at Hewlett-Packard, was first publicly elaborated by Grady and Caswell. The + was later added to the model after various campaigns at HP to extend the acronym to emphasize various attributes.
FURPS+ is now widely used in the software industry.
G. Domain Analysis
a. Domain Model
Draw the domain model and provide three tables with:
i. Concept definitions