Specifications

1. User Stories

User stories are short statements of one specific experience a user will have with the system to be built. They are expressed in 1, 2, maybe 3 sentences each, and often each is put on an index card to enforce brevity. User stories are a good starting point in getting the ideas a client has about the needed system into a concrete form.

2. Use Cases

Based on user stories and personas (which we are not using for this project), use cases capture the needed system functionality from a developer's point of view.

There are two forms of use cases that are often used: a graphical form (diagram ) that shows how the different use cases relate to each other and a textual form that talks about the details of each use case. For your projects, we will do the textual form first and then develop diagrams.

Associated with each case needs to be a description of the user, referred to as the user type, or actor. This needs to be in enough detail to allow you to reason about the task. User types may or may not map to unique use cases. For example, the one time user and the repeat user are most likely different user types. Depending on the interfaces, they may use the same interface. In this case, there will typically be an optional step of checking the help information. If they use different interfaces, they will have different use cases. Use cases should address all types of end users as well as administrators. Pay special attention to first time uses as they often have a different set of tasks that are being performed.

A single use case goes on to describe a scenario in which the actor interacts with the system to achieve some goal. The scenario will often have steps showing the order and nature of smaller actions that comprise the full behavior.

The detailed use case needs to include error cases. Identifying the error and unusual cases is one of the most valuable parts of use cases, as designers and developers often miss a number of these points.

3. Requirements

The requirements should be no more than 2 or 3 pages. It will be primarily gathered from the user stories and the use cases but will also include any specific needs of the client that are identified but not specifically written into user stories or use cases. Remembering that the requirements define the "acceptibility" of a program, you can expect me to go through the requirements at the end of the course and see if you have met them.

One of the key values of the requirements is the collecting and collapsing of information from the user stories into commonly-expresed requirement statements. Some of them may get translated into programming terms rather than domain and user terms. For example, if there are two different file structures that are needed, one of the requirements might be the consistency of the two structures. Or as you work through the different use cases of a game, you will find related behaviors; identifying how those behaviors need to be consistent might be another requirement.

Prioritize

1. definite: requirements we will definitely have functioning by semester end


2. perhaps: requirements we may well have time to get to, but not until category "definite" is done


3. improbable: requirements identified by the client that we most likely won't have time to meet this semester but not until category one is done

Requirements Categories

Functional Requirements

This subsection will most likely be the largest, and will comprise statements about functions or actions the system must perform in response to user inputs and interactions. They are basically statements that descibe correct outputs for certain inputs... "if this sort of input is given by this sort of user, then the system produces this kind of output." Not as specific as a test case, but still having the feel of Input/Output pairings... hence the name "functional" specs or requirements.

Non-functional Requirements

The video linked below give the acronym "FURPS+" to name the various kinds of requirement one might generate. "F" is for functional; "URPS+" is for

Usability
Reliability
Performance
Supportability
+design, +implementation, +physical
+interface

You can use the "URPS+" as mnemonics to help you think of any non-functional requirements your system has, but there is no need for a separate section for each heading... simply list them all in the "Non-functional Requirements" subsection.

So what are non-functional requirements? For example, a system may need the ability to port to another platform. The necessity of using a particular tool or platform might be a requirement. The need to run on old machines might also be a requirement.

If your application is not permitted to do something -- such as overwrite a file or share certain components -- you should identfy these as constraints or inverse requirements.

Interfaces
Interfaces are likely to be important requirement in many projects, so I have set them apart for special consideration. Any interactions that users or other systems have with your product are interfaces. This includes GUIs, input and output mechanisms, command lines, help screens, programming APIS and interfaces. While these may change over time, you are far ahead of the game if you begin by focusing on the externals of the system rather than the internals. Your requirements document should describe all of the interfaces that you will build (in the non-functional section). If you have agreements or requirements on the specifics of the interface, include these as well. Sketches or screen shots that have been agreed on should definitely be included.

Note that the need for your work to fit into, or interact with, some existing software or hardware system is (or causes) an interface requirement.

See the video below for a better explained list of areas from which you can draw non-functional requirements.