Case Study Requirements

Requirements – Answering the Question "What is the System Supposed to Do?"

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 and Data Requirements - that express what the user needs the system to do and include both the functions and the data.

· 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 must calculate the total of all items in the online or website shopping cart.

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

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

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

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

2. Non-Functional or "Technical" 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, the transactions and the 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 must encrypt the user's payment information when it is transmitted.

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

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

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

· The system must 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 "must" (vs. "will," "shall," "may," or "should")

· Is generally stated in positive terms; i.e., "the system must xxxx" vs. "the system must not xxx". However, in certain circumstances "must not" is more appropriate.

· 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 must ….."

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

Poorly Written Requirement	What is Wrong	Well Written Requirement
Users must have access to their personal data, which will be transmitted in a secure manner.	Two requirements – one functional and one non-functional - are expressed; each statement should express only 1 requirement.	1. The system must provide a user with access to their personal data. 2. The system must transmit personal data in a secure manner.
The system must calculate the total of all items in the online or website shopping cart and display the total to the user.	Two requirements are expressed; each statement should express only 1 requirement.	1. The system must calculate the total of all items in the online or website shopping cart. 2. The system must display the total of all items in the online or website shopping cart to the user.
Report must be provided within 5 seconds of the user clicking on "submit."	The requirement does not indicate that it is the system that must provide the report; should be stated as "The system must….."	The system must provide the report within 5 seconds of the user clicking on "submit."
The system should require the user to provide a shipping address.	Avoid the use of "should"; use "must."	The system must require the user to provide a shipping address.
The system must be easy to use.	"Easy to use" is not measurable or testable.	The system must guide the user through the steps to place an order.

Rev. 6/26/2019 2