Requirements

Steven J Zeil:

Last modified: Mar 11, 2014

Contents:
1. Basic Principles of Requirements Analysis
2. A “Classical” Approach to Requirements
2.1 Requirements Definition
2.2 Requirements Specification
2.3 A Prototype SRS outline
3. Eliciting Requirements
3.1 Viewpoint Analysis
3.2 Use Cases
3.3 User Stories
4. Formal Requirements

1. Basic Principles of Requirements Analysis

Understanding the customer’s requirements for a software system

Problems of requirements analysis

2. A “Classical” Approach to Requirements

Waterfall processes often distinguished between

2.1 Requirements Definition

Writing requirements definitions

Example (RSDIMU)

An RSDIMU consists of a skewed array of redundant inertial sensors and exemplifies the current trend for designing hardware fault tolerant inertial measurement units (IMU’s) for high reliability applications. The portion of the RSDIMU you will handle contains eight linear accelerometers mounted on the four triangular faces of a semioctahedron.

Your procedure will have two functions, both of which are a consequence of the redundancy in the sensor complement of the RSDIMU. The first function is to perform a consistency check to detect and isolate failed sensors. The second is to use the sensors found to be good by the first check to provide estimates of the vehicle’s linear acceleration expresses as components along the north, east, and down axes of a navigational frame of reference. ⋮ an RSDIMU as described here would operate as follows. With the vehicle stationary, as series of sensor readings would be taken over time, and this would comprise the calibration data set for that particular flight. During flight, the sensors would be read periodically at regular time intervals to provide input for the navigation software.

Critique

The preceding requirements mix up functional and non-functional requirements and are incomplete.

Example, Restructured

3. Physical structure:

The RSDIMU is composed of an instrument and a display. The display is discussed in Section 6.3. This section is devoted to the structure of the instrument package.

3.1 The instrument package is a semi-octahedron (a square-based pyramid) (Figure1).

3.1.1 It has four non-base faces, named A, B, C, or D.

3.1.2 Each face contains two sensors, named the x and y sensors.

3.1.2.1 Associated with each sensor is a set of misalignment angles. These are specified further in Section 2.3.2.

Rationale: There is an ideal position for each sensor, but the physical mounting may differ slightly.

3.1.2.2 The misalignment angles are assumed to be small enough (less than 5 degrees) for the sine of the angle to be approximately equal to the value of the angle expressed in radians.

3.1.3 The temperature of the face, temp, determines the temperatures of the sensors mounted on the face.

Rationale: Sensor output varies with temperature (see section 4.6).

2.2 Requirements Specification

The SRS (Software Requirements Specifications) adds detail to the requirements definition.

Characteristics of a good SRS

An SRS should be

  1. Correct;
  2. Unambiguous;
  3. Complete;
  4. Consistent;
  5. Ranked for importance and/or stability;
  6. Verifiable;
  7. Modifiable;
  8. Traceable.

Verifiability

The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized.

Experienced controllers should be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day.

Making the Subjective Objective

Property Measure
Speed processed transactions / sec.
Response time
screen refresh time
Size k bytes
Ease of use training time
number of help frames
Reliability mean time to failure
probability of unavailability
failure rate
Robustness time to restart after failure
probability of data corruption after failure
Portability % of target dependent statements
number of target systems

Requirements traceability

Requirements traceability means that related requirements are linked in some way and that requirements are (perhaps) linked to their source

Improving Traceability

2.3 A Prototype SRS outline

Table of Contents
1. Introduction
   1.1 Purpose
   1.2 Scope
   1.3 Definitions, acronyms, and abbreviations
   1.4 References
   1.5 Overview
2. Overall description
   2.1 Product perspective
   2.2 Product functions
   2.3 User characteristics
   2.4 Constraints
   2.5 Assumptions and dependencies
3. Specific requirements
     ⋮
Appendixes
Index

(Source: IEEE Std 830–1998, Recommended Practice for Software Requirements Specifications, p17)

1. Introduction

2. Overall Description

3. Specific Requirements

"This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.

Functional Requirements

“The system shall…”

These include

  1. Validity checks on the inputs
  2. Exact sequence of operations
  3. Responses to abnormal situations, including
  4. Effect of parameters
  5. Relationship of outputs to inputs, including

An example of a functional reqt section

RSDIMU/Calibration/4.1

Function: Check for Noise

Description: The variance in a number of readings taken from one sensor while the vehicle was at rest are compared to a threshold value. Sensors whose variance exceeds the threshold are marked as failed due to excessive noise.

Inputs: Face, Sensor, raw sensor data collected on ground, noise threshold

Source: raw sensor data offraw from external measurement procedure

Outputs: Sensor failure linFail & noise indicators linNoise

Destination: Edge consistency check and acceleration estimation functions

Requires: Instrument

Pre-condition: Sensor is not already marked as failed

Post-condition: linFail[Face,Sensor] and linNoise[Face,Sensor*] will be set to true if std-dev(offraw) > 3 * linstd.

Side effects: Changes to sensor status affect face status as well.

Non-functional requirements

Non-functional requirements examples

Requirements separation

Appendices

3. Eliciting Requirements

The problem of eliciting requirements is, fundamentally, based on communication between developers and stakeholders.

3.1 Viewpoint Analysis

Types of viewpoint

External viewpoints

The VORD method

Example: Checkbook balancing

Consider the design of software to balance a checkbook:

Viewpoint Identification

Services Provided

Viewpoint Documentation

Reference: Bank

Attributes: name, location, accounts list

Events: end-of-month, transaction arrival

Services: * create/close accounts * receive transactions * initiate transactions (charges)

Sub-VPs:

Reference: receive transaction (account debit)

Rationale: electronic funds transfer, may be signal from clearing house of a check received

Specification: The account balance is checked to determine if adequate. If so, confirmation of the transaction is sent, the account balance is reduced by the transaction amount, and the transaction noted in the account log. If not, the account kind is consulted for overdraft policy, and the policy routine found there is invoked.

Viewpoints: Bank, Clearing House

NF Reqts: Response of confirmation, rejection, or unable-to-process must be made within 30 seconds, with a mean response less than 0.1 seconds.

Viewpoints: Bank

3.2 Use Cases

A use case is a collection of scenarios.

Writing Use-Cases

  1. Start with a collection of scenarios
  2. Group by common user goals
  3. Define the actors
  4. Give brief descriptions of use cases
  5. Give a detailed description of the basic path
  6. Add alternative paths

Good use cases are

Example: grading tests

Grading an Assessment

Actors: Scorer

Main Path

  1. The scorer begins with an assessment and a collection of response documents.

  2. For each item in the assessment, the scorer obtains the item’s rubric. Then for each response document, the scorer goes to the item response for that same item, grades the response using that rubric, and adds the resulting score and (if provided) feedback to the result document for that response document.

  3. When all items have been graded, then the scorer computes a total score for each results document.

  4. The scorer add the score from each result document to the grade book.

Alternative: Candidate by Candidate Scoring

  1. For each candidate, the scorer goes through each of the items. For each item, the scorer obtains the item’s rubric, grades the item response using that rubric, adds the resulting score and (if provided) feedback to the result document for that response document.

Example:

Get Paid for Car Accident

Actors: Claimant, Accident victim making claim, Insurance Company, Company insuring Claimant, Agent, Insurance Company representative> processing claim

Main Success Scenario

  1. Claimant submits claim with substantiating data.
  2. Insurance Company verifies that Claimant owns a valid policy.
  3. Insurance Company assigns Agent to examine case.
  4. Agent verifies that all details are within policy guidelines.
  5. Insurance Company pays Claimant.

Extensions

1a. Submitted data is incomplete:

1a1. Insurance Company requests missing information.
1a2. Claimant supplies missing information.

2a. Claimant does not own a valid policy:

2a1. Insurance Company declines claim, notifies Claimant, records all this, and terminates proceedings.

3a. No Agents are available at this time:

3a1. (What does the Insurance Company do here?)

4a. Accident violates basic policy guidelines:

4a1. Insurance Company declines claim, notifies Claimant, records all this, and terminates proceedings.

4b. Accident violates some minor policy guidelines :

4b1. Insurance Company begins negotiation with Claimant as to degree of payment to be made.

(Adolph)

A poor use case

Register for Course

  1. Display a blank schedule.
  2. Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule.
  3. Do
  4. Student clicks on a course.
  5. Update the lower window to show the times the course is available.
  6. Student clicks on a course time and then clicks on the “Add Course” button.
  7. Check if the Student has the necessary prerequisites and that the course offering is open.
  8. If the course is open and the Student has the necessary prerequisites, add the Student to the course. Display the updated schedule showing the new course. If no, put up a message, “You are missing the prerequisites. Choose another course.”
  9. Mark the course offering as “enrolled” in the schedule.
  10. End do when the Student clicks on “Save Schedule.”
  11. Save the schedule and return to the main selection screen.

Problems:

Register for Course

  1. Student requests a new schedule.
  2. The system prepares a blank schedule form and pulls in a list of open and available courses from the Course Catalog System.
  3. Student selects primary and alternate courses from the available offerings.
  4. For each course, the system verifies that the Student has the necessary prerequisites and adds the Student to the course, marking the Student as “enrolled” in that course in the schedule.
  5. When the Student indicates the schedule is complete, the system saves the schedule.

Use Cases and Requirements

Use cases fall somewhere between reqts. definition and reqts. specification.

3.3 User Stories

A user story is a mechanism for incremental requirements elicitation and analysis.

Examples of User Stories

As a calendar owner, I want to view my schedule for the coming week.

As a visitor, I want to see when a calendar owner has free time in their schedule.

As a calendar owner, I want to receive email notication when someone accepts a proposed appointment.

As a systems administrator, I want to back up all calendars so that the data is safeguarded.

These illustrate some common patterns:

Story Boards

storyBoardImg

Stories are not Requirements

4. Formal Requirements

There is always a dedicated group of advocates who maintain that the use of natural language in requirements specifications is a fundamental flaw.

.