Software Requirements
Edited by : Naif Alzahrani
4
Lab 4: Software Requirements
Objectives
Learn how to write requirements and specifications.
1. Outline
Review of the requirements engineering process.
Write requirements and.
2. Background
A requirement is a statement of a behavior or attribute that a system must possess for the system to be acceptable to a stakeholder.
System requirements make explicit the characteristics of the system-to- be. Requirements are usually divided into functional and non-functional.
Functional requirements determine the system’s expected behavior and the effects it should produce in the problem domain. These requirements generally represent the main product features.
Non-functional requirements describe some quality characteristic that the system-to-be shall exhibit. They are also known as “quality” or
“emergent” requirements, or the “-ilities” of the system-to-be. An example non-functional requirement is: Maintain a persistent data backup, for the cases of power outages.
2.1 Requirements Engineering Process
Requirements engineering process consists of four phases:
Requirements elicitation: getting the customers to state exactly what the requirements are.
Requirements analysis: making qualitative judgments and checking for consistency and feasibility of requirements.
Requirements validation: demonstrating that the requirements define the system that the customer really wants.
Requirements management: the process of managing changing requirements during the requirements engineering process and system development, and identifying missing and extra requirements.
2.2 Writing Requirements
Requirements always need to be correct, unambiguous, complete, consistent, and testable.
2.2.1 Recommendations When Writing Requirements
Never assume: others do now know what you have in mind.
Use meaningful words; avoid words like: process, manage, perform, handle, and support.
State requirements not features:
o
Feature: general, tested only for existence.
o
Requirement: specific, testable, measurable.
Avoid:
o
Conjunctions: ask yourself whether the requirement should it be split into two requirements.
o
Conditionals: if, else, but, except, although.
o
Possibilities: may, might, probably, usually.
3. Exercises:
A- Consider the following problem
You are hired to develop an automatic patient monitoring system for a home-bound patient. The system is required to read out the patient’s heart rate and blood pressure and compare them against specified safe ranges. The system also has activity sensors to detect when the patient is exercising and adjust the safe ranges. In case an abnormality is detected, the system must alert a remote hospital. (Note that the measurements cannot be taken
continuously, since heart rate is measured over a period of time, say 1 minute, and it takes time to inflate the blood-pressure cuff.) The system must also (i) check that the analog devices for
measuring the patient’s vital signs are working correctly and report failures to the hospital; and, (ii) alert the owner when the battery power is running low.
Write the requirements for this system and prioritize them.
B-
Consider the following nonfunctional requirements and determine which of them can be verified and which cannot. Write acceptance tests for each requirement or explain why it is not testable.(a) “The user interface must be user-friendly and easy to use.”
(b) “The number of mouse clicks the user needs to perform when navigating to any window of the system’s user interface must be less than 10.”
(c) “The user interface of the new system must be simple enough so that any user can use it with a minimum training.”
(d) “The maximum latency from the moment the user clicks a hyperlink in a web page until the rendering of the new web page starts is 1 second over a broadband connection.”
(e) “In case of failure, the system must be easy to recover and must suffer minimum loss of important data
