Software Req

8/3/2019 Software Req

1/39

LECTURE 3

SOFTWARE REQUIREMENTS

CSE 2142 Software Engineering


2/39

Objectives

To introduce the concepts of requirements

To describe functional /non-functionalrequirements

To explain techniques for describing

requirements.

To explain how software requirements may

be organised in a requirements document.

2


3/39

Introduction

In engineering a requirement is a singulardocumented need of what a particular productor service should be or perform.

It is a statement that identifies a necessaryattribute, capability, characteristic, or quality of asystem in order for it to have value and utility toa user.

The sets of requirements are used as inputs into

the design stages of product development.

3


4/39

Introduction

Requirements are also an important input intothe verification process, since tests should traceback to specific requirements.

Requirements show what elements andfunctions are necessary for the particularproject.

4


5/39

The notion of a requirement

Requirement Engineering : The process of

establishing the services that the customer requires

from a system and the constraints under which it

operates and is developed

Definition of Requirement [IEEE]:

a condition or capability needed by a user to solve a

problem or achieve an objective

a condition or capability that must be met or possessed by

a system or system component to satisfy a contract,

standard, specification or other formally imposed

documents

5


6/39

Types of requirement (1)

Requirements must be presented in alternative, but

consistent forms that are understandable to different

audiences. May range from a high-level abstract

statement of a service or of a system constraint to a

detailed mathematical functional specification.

1. User requirements: Statements in natural language,

diagrams of the services the system provides and its

operational constraints that are written for customers

6


7/39

Types of requirement(2)

1. System requirements: A structured document

setting out detailed descriptions of the systems

services and constraints. This document is usually

written as a contract between the client and the

contractor.

2. Software design specification: A detailed software

description which can serve as a basis for design and

implementation. This design specification is written

for developers and is usually a detailed version of the

system requirements.

7


8/39

Example8


9/39

Readers of Requirements

System customers:Specify therequirements and then read tocheck that the requirementsmeet their needs.

Managers : Use requirement

document to estimate a price forthe system and also plan theproject.

System Engineers: Use therequirements to understand whatsystem is to be developed.

System test engineers: Use therequirement to develop validationtests.

System Maintenanceengineers: Use requirement

document to understand the

9

UserRequirements

Client managersSystem end-usersClient engineersContractmanagersSystem architects

System end-usersClient engineersSystemarchitects

SoftwareDeveloper

SystemRequirements

SoftwareDevelopersClient engineersSystemarchitects

Softwaredesignspecification


10/39

Requirements Classification(1)

User Requirements Should describefunctional and non-functional requirementsso that they are understandable by system

users who dont have detailed technicalknowledge

Functional requirements:

A functional requirement is a description of whata system must do.

It is written down as statements of services thatthe software should provide, how the software

should react to particular inputs and how the

10


11/39

Requirements Classification(2)

Non-functional requirements:

Non functional requirement specifies somethingabout the software itself, and how well it performs

its functions. constraints on the services or functions offered by

the software, such as, timing constraints,constraints on the development process, standards,

and so on.

11


12/39

Functional Requirements

Functional requirements are statements that

describe the functionality that the system is toexecute; for example, formatting some text.

Descriptions of data to be entered into the system

Descriptions of operations performed.

Examples:

The user shallbe able to search either all of the initial

set of databases or select a subset from it The system shallprovide appropriate viewers for the

user to read documents in the document store

Every order shallbe allocated a unique identifierwhich the user shall be able to copy to the accounts

permanent storage area.

12


13/39

Requirements imprecision (1)

Problems arise when requirements are not preciselystated

Ambiguous requirements may be interpreted in differentways by developers and users

Consider the term appropriate viewers

User intention - special purpose viewer for eachdifferent document type

Developer interpretation - Provide a text viewer thatshows the contents of the document

In principle requirements should be both completeand consistent

13


14/39

Requirements imprecision(2)

Complete

They should include descriptions of all facilitiesrequired

Consistent There should be no conflicts or contradictions in the

descriptions of the system facilities

In practice, it is very difficult or impossible to produce a

complete and consistent requirements document

14


15/39

Non-Functional Requirements

Non functional requirements are those requirements arethe ones that act to constrain the solution.

Quality attribute

requirements(Dependability,Performance,Accuracy,Security)

Project Constraints (Maximum cost,Maximumschedule)

Design directives(sorting shall be done usingQuicksort algorithm)

Implementation directives (Software shall be written inC)

15


16/39

NFR Classification16


17/39

Verifiable NFR

Non-functional requirements may be very difficult tostate precisely and imprecise requirements may bedifficult to verify.

A verifiable non-functional requirement

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

The table in the next slide give some measures thatcan be used to specify non-functional requirementsthat can be verified.

17


18/39

Requirement Measures18


19/39


Design constraints include the fact that the softwaremust run using a certain database system or that thesoftware must fit into the memory of a 512Kbytemachine.

Performance requirements: for example 95% ofcatalogue database queries shall be completed within 2seconds.

Security: Access to student records shall be password-protected so that only authorized people can view them.

Reliability requirements: for instance, the acceptablefailure rate or the amount of time that the system will

19


20/39


Usability requirements: The interface shall bemenu-driven, so that it is easy to learn and use.

Design directives: They tell the developer how

to design certain functionality of the software.For example, The sorting of the student recordsshall be done using Quicksort algorithm.

Implementation directives: They tell thedeveloper what to use to implement certainfunctionality of the software. For example, TheSoftware shall be written in java such that it canbe portable onto different operating system

platform.

20


21/39

Characteristics of goodrequirement

21

Unitary (Cohesive)The requirement addresses one andonly one thing.

CompleteThe requirement is fully stated in oneplace with no missing information.

ConsistentThe requirement does not contradictany other requirement

Non-Conjugated(Atomic)

The requirement is atomic, i.e., it doesnot contain conjunctions. E.g., "The

postal code field must validateAmerican andCanadian postal codes"should be written as two separaterequirements: (1) "The postal code field

must validate American postal codes"and (2) "The postal code field must


22/39

Characteristics of goodrequirement

22

TraceableThe requirement meets all or part of a businessneed as stated by stakeholders andauthoritatively documented.

FeasibleThe requirement can be implemented within the

constraints of the project.

Unambiguous

The requirement is concisely stated withoutrecourse to technical jargon, acronyms (unlessdefined elsewhere in the Requirementsdocument).

Mandatory

The requirement represents a stakeholder-defined characteristic the absence of which willresult in a deficiency that cannot beameliorated.

Verifiable

The implementation of the requirement can be

determined through one of four possiblemethods: inspection, demonstration, test or


23/39

Guidelines for writing

requirements(1)

Invent a standard format for numbering therequirement. The simplest approach is to give everyrequirement a unique sequence number, such as UR-2or SRS13. The most commonly used convention is

hierarchical numbering. If the functional requirementsappear in section 3.2 of your requirement document,they will all have labels that start by 3.2, for example,3.2.1 The system shall compute the salary ofemployee based on the time-sheet.

Use language consistently; for example, definemandatory requirement using shall and desirablerequirement using should.

23


24/39

Guidelines for writing

requirements(2)

Avoid, as far as possible, the use of computer jargon todescribe requirement. However, it will be inevitablewhen providing technical details.

To reduce ambiguity, avoid vague, subjective termssuch as user-friendly, easy, simple, rapid,efficient,support,several,superior,acceptable,and robust. Find out what the customers really meanwhen they say user-friendly or fast or robust and

state those expectations in the requirements.

Avoid comparative words such as improve,maximize, minimize, and optimize. Quantify the

degree of improvement that is needed, or state the

24


25/39

Requirements Analysis (1)

Analyse requirements in order to identify &

Resolve:

Ambiguities : different interpretations of naturallanguage

E.g: If the central computer receives an alarm signal from

the

local process-control computer, it will shut down.

Platitudes: Vague FRs and non-measurable NFRs

which leads to untestable/untraceable requirements

E.g: System shall be user-friendly, System shall be

25


26/39

Requirements Analysis (2)

Inconsistencies: Contradictory statements

After validating input lists, only alphabetically sorted lists remain.

Later on: If a validated list is not in alphabetical order, an error

message shall be displayed

Mixtures of abstraction : Different levels of detail in the same section

The PAYROLL subsystem performs all the functions related to staff

payment. The OVERTIME module computes the overtime paymentfor the employee currently being processed based on the time-sheet

for the current week.

FRs and NFRs mixed up

The OVERTIME subsystem shall be written in Java and computes the

overtime for an employee based on his time-sheet.

26


27/39

Requirements interaction

Conflicts between different non-functional requirements arecommon in complex systems

Spacecraft system

To minimise weight, the number of separate chipsin the system should be minimised

To minimise power consumption,

lower power chips should be used

However, using low power chips

may mean that more chips have

to be used.

Which is the most critical requirement?

27

P bl i h l l


28/39

Problems with natural language(1) Lack of clarity

Precision is difficult without making the documentdifficult to read

Requirements confusion

Functional and non-functional requirements tend to bemixed-up

Requirements amalgamation Several different requirements may be expressed

together

28

P bl ith t l


29/39

Problems with naturallanguage(2) Ambiguity

The readers and writers of the requirement mustinterpret the same words in the same way. NL isnaturally ambiguous so this is very difficult

Over-flexibility

The same thing may be said in a number of differentways in the specification

Lack of modularisation

NL structures are inadequate to structure systemrequirements

29


30/39

Alternative to Natural Language

Structural natural language: This approach depends ondefining standard forms or templates to express therequirements specification.

Design description language: It uses a language likeprogramming language but with more abstract features tospecify the requirement by defining an operational model ofthe system.

Graphical notations: A graphical language, supplementedby test annotations is used to define the functionalrequirements for the system. The most common graphicalrepresentation is Use-Case

Formal specifications:Requirements are specified, byusing mathematically precise formal logic languages ornotations based on mathematical concepts such as finite-state machines or sets.

30

St t d l


31/39

Structured languagespecifications

A limited form of natural language may be usedto express requirements

Often best supported using a Form-based

specifications, Special-purpose forms wheredesigned to describe the input, output andfunctions of a software system Definition of the function or entity

Description of inputs and where they come from

Description of outputs and where they go to

Indication of other entities required

Pre and post conditions (if appropriate)

The side effects (if any)

31


32/39

32

PDL based specifications

Requirements may be defined operationally using a language like aprogramming language but with more flexibility of expression

Most appropriate in two situations

Where an operation is specified as a sequence of actions and the

order is important When hardware and software interfaces have to be specified

Disadvantages are

The PDL may not be sufficiently expressive to define domainconcepts

The specification will be taken as a design rather than aspecification.

PDL may not be sufficiently expressive to express the systemfunctionality in an understandable way

Notation is only understandable to people with programminglanguage knowledge

S ft R i t


33/39

Software RequirementsSpecification Software Requirements Specification (SRS): It is the official statement of what is required of the

system developers. The requirements are recorded inone or more form including natural language, formal,symbolic or graphical representations.

The primary purposes of documentingrequirements in only one document is to ensurethat: Customers and developers have the same understanding

of what is to be built.

All developers have identical understanding of what is tobe built.

Testers are testing for the same qualities that developersare building.

Management is applying resources to the same set of

33


34/39

34

Requirements Specifications

1.The software shall provide a means of representingand accessing external files created by other tools

1.1 The user should be provided with facilities to define thetype of external files

1.2 Each external file type may have an associated toolwhich may be applied to the file

1.3 Each external files type may be presented as a specificicon on the users display

The specifications adds detail to the requirementsdefinition and should be consistent with therequirements definition. Usually presented withsystem models


35/39

35

Audiences for SRS(1)

Customers and the marketing department rely onthe SRS to know what product they can expect to bedelivered.

Project managers base their plans and estimates ofschedule, effort, and resources on the productdescription contained in the SRS.

The software development team relies on the SRSto understand what is to be built.

The testing group uses the product behaviordescriptions contained in the SRS to derive testplans, cases, and procedures.


36/39

36

Audiences for SRS(2)

Software maintenance and support staff refer to theSRS to understand what each part of the product issupposed to do.

The publications group writes user documentation,such as manuals and help screens, based on boththe SRS and the user interface design.

Training personnel can use both the SRS and theuser documentation to help them developeducational materials.


37/39

37

Characteristics of Document

Correct : Free from errors

Unambiguous, precise & clear : One and onlyone interpretation for every requirement

Complete : All requirements for the problem identified &specified

Testable : By quantitative means

Consistent : No conflicting requirements

Modifiable: This attribute is more concerned with theformat & style of the SRS rather than the actual requirementsthemselves

Traceable : Backward & Forward traceability


38/39

Guidelines(1)38

Introduction

Purpose of document Intended audience, how is the SRS document tobe used?

Scope What are the boundaries of the specifiedsystem?

Definitions & notations: High-level definitions used throughout documente.g. Acct. No., TRX, Ref. No.

References Sources of information concerning the currentsystem.

GeneralDescription

Product perspective Context diagram, relationship between system &its environment

Product functions Brief description of the primary functions

Characteristics of eventual users Required background or training

Constraints Hardware limitations, Implementation &

language requirements


39/39

Guidelines(2)39

System Architecture Present a high-level overview of theanticipated system architecture showing thedistribution of functions across systemmodules

Specific Requirements Functional Requirements: Can be expressed

by using natural language, formal, symbolicor graphical representationsNon functional Requirements: Can beexpressed using natural language, formal,symbolic or graphical representations.

AppendicesProvide detailed, specific informationwhich is related to the application whichis being developed. (Hardwaredescriptions)

Index Page numbers of important section and sub-sections

Documents

Software Req