Stage 3

The requirement statement:

· Is a complete sentence, with a subject (system) and predicate (intended result, action or condition)

· Identifies only one requirement; does not include the words "and," "also," "with," and "or."

· For Functional Requirements, states what tasks the system will support or perform

· For Non-Functional Requirements, states how the system will perform.

· Includes a measure or metric that can be used to determine whether the requirement is met (time or quantity), where appropriate

· Is stated in positive terms and uses "shall" (not "may" or "should"); "the system shall xxxx" not "the system shall not xxx"

· Avoids the use of terms that cannot be defined and measured, such as "approximately," "robust," "user friendly," etc.

· Is achievable; avoids terms such as "100% uptime," or "no failures"

The Basics

For purposes of this class, we will focus on what the end user needs or expects the system to do. These needs and expectations are documented as requirements for the system. They fall into two general categories:

1. Functional Requirements - that express what the user needs the system to do.

· They describe the tasks the users need to accomplish with the system

· What data the user will input

· What the system is expected to do with the data that is input

· What the system is expected to provide as output (reports, results, etc.)

Example functional requirements:

· The system shall calculate the total of all items in the online or website shopping cart.

· The system shall display to the user similar items that the online shopper may be interested in.

· The system shall require the user to provide a shipping address.

· The system shall automatically fill in the State portion of the shipping address based on the zip code entered by the user.

· The system shall provide the user with a report of all purchases made via the website.

2. Non-Functional Requirements – that express how the system will perform.

· They describe how the system will perform in areas such as:

· Usability – Ability for new users to quickly adapt to the software, including how easy the system is to use and how help is provided for the users

· Scalability – Ability of the system to accommodate additional users and/or additional records/transactions

· Availability – Amount or periods of time the system is to be operational and useable

· Reliability – Ability of the system to create and maintain the data correctly

· Maintainability – Ability of the system to be easily maintained, corrected and updated

· Portability – Ability of the system to run/operate on a variety of end-user devices or with multiple operating systems

· Or, they describe security requirements for the system and data, such as:

· Protection of data as it is transmitted and when it is stored

· User authentication

· Authorization of user to perform specific functions

· Data backup and recovery

Example non-functional requirements:

· The system shall encrypt the user's payment information when it is transmitted.

· The system shall store the user's full name in the database.

· The system shall require a retinal scan for login purposes.

· The system shall be capable of handling 5,000,000 transactions per hour.

· The system shall operate using Motorola hand-held scanners.

Writing the Requirements Statements

The requirement statement:

· Either states what the system will do as a functional requirement, or states how the system will do it as a non-functional requirement (Never both together)

· Identifies only one requirement; avoid the words "and," "also," "with," and "or"

· Is a complete sentence, with a subject (usually "the system") and predicate (intended result, action or condition)

· Uses "shall" (vs. "may" or "should")

· Is stated in positive terms; i.e., "the system shall xxxx" vs. "the system shall not xxx"

· Avoids the use of terms that cannot be defined and measured, such as "approximately," "robust," "user friendly," etc.

· Is achievable; avoids terms such as "100% uptime," or "no failures"

· Is complete; it includes a measure or metric (time or quantity) where appropriate

· Must be testable; that is, there must be some way to test the system to determine whether a requirement is met

· Generally is written as "The system shall ….."

Below are some examples of poorly written and well-written requirements, with an explanation of what is wrong with the poorly written one.