What are Requirements?

"The hardest single part of building a system is deciding what to build... No other part of the work so cripples the

resulting system if done wrong. No other part is more difficult to rectify later."

-- Fred Brooks

Product Engineering

System analysis(World view)

The completeproduct

capabilities

Componentengineering

(Domain view)

Processing requirement

Analysis & DesignModeling

(Element view)

Construction&

Integration(Detailed view)

software

function

SoftwareEngineering

programcomponent

hardware

data behavior

Definitions

Software Requirements Descriptions of the services and constraints of a software system Tells what to build, not how to build it.

Why Spend a Lot of Time?Requirements are the source for all future steps in the software life cycle

Lays the basis for a mutual understanding• Consumer (what they get)• Software producer (what they build)

Identifies fundamental assumptions Potential basis for future contracts

Better get it right - upon delivery, some software is rejected by customers

Changes are cheap - better make them now rather than later

Types of Requirements

Functional vs. Non-functional vs. Domain Reqs Focuses on the visible and invisible features of the software

system and the constraints intrinsic to its application space

User vs. System Requirements Focuses on the User or the System perspective

Functional Non-functional

User Most user reqs are specified as functional

End users do not typically specify; come out of analysis

System System-level standards, such as standard GUI

Many such reqs may be specified here

Functional requirements

Describe functionality or system services Depend on the type of software, expected users and the type of

system where the software is used Functional user requirements are high-level statements of what

the system should do but functional system requirements should describe the system services in detail

Examples “The user shall be able to search either all of the initial set of

databases or select a subset from it.”

“The system shall provide appropriate viewers for the user to read documents in the document store. “

“Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.”

Non-functional requirements

Define system properties and constraints e.g. reliability, response time and storage requirements Constraints are I/O device capability, system representations, etc.

Process requirements may also be specified mandating a particular CASE system, programming language or development method

Non-functional requirements may be more critical than functional requirements. If not met, the system is useless

Non-functional classifications

Product requirements Requirements which specify that the delivered product must behave in a

particular way e.g. execution speed, reliability, etc. Example: “4.C.8 It shall be possible for all necessary communication between

the APSE and the user to be expressed in the standard Ada character set”

Organisational requirements Requirements which are a consequence of organisational policies and

procedures e.g. process standards used, implementation requirements, etc. Example: “9.3.2 The system development process and deliverable documents

shall conform to the process and deliverables defined in XYZCo-SP-STAN-95”

External requirements Requirements which arise from factors which are external to the system and

its development process e.g. interoperability requirements, legislative requirements, etc.

Example: “7.6.5 The system shall not disclose any personal information about customers apart from btheir name and reference number to the operators of the system”

Non-functional requirement types

User vs. System Requirements

User requirements Statements in natural language plus diagrams of the services the

system provides and its operational constraints. Written for customers

Should describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge

User requirements are defined using natural language, tables and diagrams

System requirements A structured document setting out detailed descriptions of the

system services. A contract between client and contractor More detailed specifications of user requirements Serve as an initial basis for designing the system

Domain requirements

Derived from the application domain and describe system characteristics and features that reflect the domain May be new functional requirements, constraints on existing

requirements, or define specific computations If domain reqs are not satisfied, the system may be unworkable

Typically elicited from domain experts (doctors, lawyers, etc.) or domain-specific standards documents (procedures).

Problems Understandability

• Requirements are expressed in the language of the application domain• This is often not understood by software engineers developing the system

Implicitness• Domain specialists understand the area so well that they do not think of

making the domain requirements explicit

Examples: “Patient information modules must conform to the HL-7 data standards” “The eLearning delivery platform must be ADA-508 compliant”

Requirements Examples

Specify whether the following are Functional, Nonfunctional, and/or Domain

• If nonfunctional, are they Product, Organizational, or External? System or User

1. “The user shall be able to toggle between displaying and hiding all HTML markup tags In the document being edited with the activation of a specific triggering mechanism.”2. “The online credit-card payment facility shall support a minimum of 1000 credit-card transactions per hour”.3. “The doctor shall be able to search the patient tracking system for similar symptoms By typing keywords into a dialog box on the application’s main web page.”

4. “The XML-based content management system shall support UTF-8 encoding”5. “The system shall be up and running 99.9999% of the time”.6. “The system shall support the EDI standard for medical patient data exchange”7. “The user shall save files by selecting the’FileSave’ menu choice”

Other Requirements Classifications

• Change is a Risk! The priority of requirements from different viewpoints changes during

the development process System customers may specify requirements from a business

perspective that conflict with end-user requirements The business and technical environment of the system changes

during its development

• Enduring requirements Stable requirements derived from the core activity of the customer

organisation. e.g. a hospital will always have doctors, nurses, etc. May be derived from domain models

• Volatile requirements Requirements which change during development or when the system

is in use. e.g. In a hospital, requirements derived from health-care policy

Summary

• Requirements are the representation of what the customer wants not how you will implement it.

• Requirements can be classified several ways: Functional vs. Non-functional User vs. System Domain-specific vs. domain-independent Enduring vs. Volatile

• Requirements can be annotated to help manage change

Dr. Gary’s tip: Annotate your features and requirements!!! For each feature/requirement, note the classification above For each feature/requirement, annotate in as many ways that

are useful to managing the scope of impact when they change

Requirements Checklist Example

Attribute Values Description

1. Verifiable Yes/No Can you (did you) write a test to check for it?

2. Traceable GUID Assign a unique identifier to the feature/req

3. Volatility % 0% = Enduring, 100% = (very) Volatile

4. Behavioral Funct/NF if NF, classify (slide 7-8, WhatAreReqs slides

5. Perspective User/System

6. Domain-specific Yes/No if Yes, describe source

7. Priority High/Med/Low Later you can use “scale of 1 to 10” or biz value

Example:REQ V T Vol. B P D Pri Notes

R1 No BN0 10% F U Y L Stable; but need a test

R2 Yes XYZ1 50% F U N M Worried user may change mind

R3 No 80% NF-Org S N H We don’t understand at all!