Requirement Document Template

Use this template to complete your requirements document.

From the Project Milestones we have....

A Requirements document is..."An extended document that details all functional requirements of the deliverable prototype...etc"

• You should want to remind the reader about the ultimate goal(s) of the system you are developing. Use the 'General Description of Target System' to do this. This section should be similar to the Project Description section of the Project Plan, revised according to comments received by the instructor/customer.
• A good way to begin to understand what your system will do is to think up a set of common usage scenarios that you anticipate end-users will want to see supported by the system you will deliver. These scenarios are stories of how the system will be used and should be as concrete and descriptive as possible.
• Another way to get you thinking more concretely about requirements is to storyboard how you envision the system you will build. A storyboard is a quick paper and pencil depiction of how the system will appear to its end users. The storyboard is an inexpensive way to begin to get some reaction from your customer as to how a system will look and function. The idea behind the storyboard is that it is easy to generate and easy to change. You will probably go through several iterations of a storyboard for your product before you begin to settle on a view of the system you will be designing that meets your customer's satisfaction and you feel you can build.
• The previous two exercises were meant to get you thinking concretely about the system you will build. Now it's time to get a little more structured and thoughtful. The requirements document is intended to detail several types of requirements on the system you will build. First, there are the functional requirements, which detail what basic operations your system will deliver. The scenarios and storyboards mainly focussed on the functional behavior. For the functional requirements we suggest that you first try to decompose the functionality of your system into self-contained features. For instance, a personal information management system will most likely contain a printing facility which is a self-contained feature. Describe and explain what each feature means, decomposing it into smaller features, if necessary.
  • Because your time is limited and you are not expert in predicting how long it will take to design and implement each of the features listed as functional requirements, it is important that you list the functional features in order of importance. If one feature denotes a group of sub-features, then write these indented and underneath the main one (i.e., use the classic table of content format). Adapt this scheme as you see it fit. To the reader, it should be clear in what order the functional elements of the system will be implemented and which features depend on other features.
  • If you think you know a better way to do it then please do so. Remember that your method must convey the functional requirements clearly.

• Non-functional requirements deal with the environment in which your system evolves. This might refer to external standards that your system must adhere to, particular usability constraints (maybe you will have to cater to a highly skilled user population, or perhaps a handicapped population). Non-functional requirements do not refer directly to services that the system will deliver; rather, they refer to the way in which those services must be provided or constraints that the environment of the system's use will impact on the development (e.g., response to all user requests must be answered within 2 seconds in all cases). Whatever you consider a non-functional requirement, it is MANDATORY that you be very specific how that requirement is to be evaluated or tested in the final product.

• A particular class of non-functional requirements are those concerned with the Platform and Network Environment. Here, you need to clearly indicate under which platform and network environment conditions you intend to operate.

• Use the risk assessment section to inform us of the main risks that you see developing that system. Remember that these span the substance of every sections listed above (func., non-func. requirements, and platform). Assessing risk is important to help you identify what things might go wrong in designing the system you are proposing (such as required hardware not arriving or being faulty). For each risk, you need to identify what your plan will be to address the risk in the case it becomes a reality.

[Project Name] Project Plan

v

Spring Quarter 1996 1/29/96 Document Author: Name of author Project Sponsors: GregoryAbowd Others?

[Project Name] Team: Name (Manager) Name (Architect) Name (Programmer) Name (Technical Writer)

Project Description of Target System

Scenario descriptions

Storyboarding

Functional Requirement

Non-Functional Requirement

Development and Target Platforms

Risk Analysis