1

Chapter 4:

Software Requirements

2

Overview

What are software requirements?

Functional requirements

Non functional requirements

Domain requirements

User and system requirements

Interface specification

Why is it important to get it right?

The SRS document

3

By the end of this chapter, you will..

Understand the concept of software requirements

Understand the difference between functional and non

functional requirements

Understand the importance of getting it right.

Understand how requirements are documented (the SRS

document)

4

What are software requirements?

“The descriptions of the system services and constraints that are generated during the requirements engineering process.”

Developed during the first phase in the software development life cycle.

5

The LIBSYS case study

A library system that provides a single interface to a number of databases of articles in different libraries.

Users can search for, download and print these articles for personal study.

6

Requirements Types

Functional requirements

Non-functional requirements

Domain requirements

7

1. 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 requirements can be

User requirements are high-level statements of what the system should do

System requirements should describe the system services in detail

8

The user shall be able to search either all of the initial set of databases or

select a subset from it.

Example 1:

9

The system shall provide appropriate viewers for the user to read

documents in the document store.

Example 2:

10

Problems with Requirements

Problems arise when requirements are not precisely stated (Ambiguous)

Ambiguous requirements may be interpreted in different ways by developers and users.

11

2. Non-Functional Requirements

• Reliability, Response time, Maintainability, Storage requirements

System properties

• I/O device capability, Data representations

Constraints

• Mandating a particular CASE system, Programming language or Development method

Process requirements

12

Types of Non-Functional Requirements

13

Examples of Non-Functional Requirements

Product requirementThe user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.

Organisational requirementThe system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.

External requirementThe system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

14

Which do you think is more critical,

A functional or non-functional requirement? Why?

Question:

Have a look at the following case study..

15

Europeana Project

http://en.wikipedia.org/wiki/Europeana

16

Verifiable Non-Functional Requirements

Non-functional requirements may be very difficult to state precisely

Imprecise requirements may be difficult to verify.

Therefore we need a statement using some measure that can be objectively tested.

17

Verifiable Non-Functional Requirements

Example: The system shall be easy to use

Better expressed as:

Experienced users shall 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 shall not exceed two per day.

18

Requirements’ Measures

Property Measure

Speed Processed transactions/second

User/Event response time

Screen refresh time

Size M Bytes

Number of ROM chips

Ease of use Training time

Number of help frames

Reliability Mean time to failure

Probability of unavailability

Rate of failure occurrence

Availability

Robustness Time to restart after failure

Percentage of events causing failure

Probability of data corruption on failure

Portability Percentage of target dependent statements

Number of target systems

19

3. Domain Requirements

Derived from the application domain and describe system characteristics and features that reflect the domain.

Domain requirements may be new functional requirements, constraints on existing requirements or define specific computations.

20

3. Domain Requirements (Example)

The deceleration of the train shall be computed as:

Dtrain = Dcontrol + Dgradient

where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train.

21

Guidelines for writing requirements

Invent a standard format and use it for all requirements.

Use language in a consistent way.

Use shall for mandatory requirements, should for desirable requirements.

Use text highlighting to identify key parts of the requirement.

Avoid the use of computer jargon.

22

User & System Requirements

User Requirements System Requirements

Written for customers

Statements in natural language

Describe the services the system provides and its operational constraints.

May include diagrams or tables

Should describe functional and non-functional requirements

Should be understandable by system users who don’t have detailed technical knowledge.

Statements that set out detailed descriptions of the system’s functions, services and operational constraints.

Defines what should be implemented so may be part of a contract between client and contractor.

Intended to be a basis for designing the system.

Can be illustrated using system models

We provide a definition for a user requirement.

We provide a specification for a system requirement.

23

Definition & Specification

User requirement definition

The software must provide a means of representing and accessing external files created by other tools.

System requirements specification

1.1 The user should be provided with facilities to define the type of external files.

1.2 Each external file type may have an associated tool which may be applied to the file.

1.3 Each external file type may be represented as a specific icon on the user’s display.

1.4 Facilities should be provided for the icon representing an external file type to be defined by the user.

1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon.

24

Interface Specification

Most systems must operate with other systems and the operating interfaces must be specified as part of the requirements.

25

Why is it important to get it right?

If you don’t do it right you will build a very elegant software solution that solves the wrong problem.

the result is project failure wasted time, and money, personnel frustration, and customer dissatisfaction

26

27

Representing requirements

The SRS document

The Software Requirements Specification (SRS) document is the official statement of what is required of the system developers

28

Representing requirements

The SRS document

Should include both a definition of user requirements and a specification of the system requirements.

It is NOT a design document. As far as possible, it should set WHAT the system should do rather than HOW it should do it.

29

Representing requirements

Users of the SRS document

30

Structure of the SRS document

Preface Introduction Glossary User requirements definition System architecture (high level) System requirements specification System models System evolution Appendices Index

31

Requirements Engineering Process

“The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.”

The result is a specification :“representing the requirements in a manner that ultimately leads to successful software implementation.”

32

Requirements Engineering Process

+ Requirements Management

33

Requirements Engineering Process

1. Feasibility Study

A feasibility study decides whether or not the proposed system is worthwhile.

A short focused study that checks If the system contributes to organisational objectives; If the system can be engineered using current technology and within budget; If the system can be integrated with other systems that are used.

34

Requirements Engineering Process

2. Requirements Elicitation

Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.

May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

Can you identify possible stakeholders for the LIBSYS?

35

Requirements Engineering Process

2. Requirements Elicitation

Requirements Discovery Sources of information Documentation System stakeholders Interviews Observation (ethnography)

Specifications of similar systems

36

Requirements Engineering Process

2. Requirements Elicitation

Requirements Analysis (System Models) The model aids the analyst in understanding the system, thereby makes the requirements analysis easier and more systematic. The model becomes the focal point of review. The model becomes foundation for design. Produced during requirements analysis.

More on modeling in chapter 5

37

Requirements Engineering Process

3. Requirements Specification

It is the final work product produced by the requirements engineer. The SRS document It serves as a foundation for the software design and implementation.

38

Requirements Engineering Process

4. Requirements Validation

The process of ensuring that the requirements actually define the system that the customer wants. Why is it important?

The cost of fixing a requirements problem by making a system change is much greater than repairing design or coding errors.

39

Requirements Engineering Process

4. Requirements Validation /Checks

Validity checks Is this what the user wants?

Consistency checks Requirements should not conflict

Completeness checks Requirements should define all functions and constraints

Realism checks Ensure they could be implemented

Verifiability Requirements should be written so that they are verifiable, you should be able to write tests for each requirement.

40

Requirements Engineering Process

4. Requirements Validation /Techniques

Requirements reviews A team of reviewers manually check the requirements.

Prototyping An executable model of the system is demonstrated to customers.

Test-case generation Requirements should be testable. If tests are difficult or impossible to design, this means that the requirements will be difficult to implement. Developing tests before any code is written is used in ----?.

41

Requirements Engineering Process

5. Requirements Management

Why? Requirements for large software systems are always changing. Because the problem can not be fully specified, the requirements are usually incomplete and bound to change. During the software process the stakeholders understanding of the problem is constantly changing After the system is installed, new requirements will emerge.

What? It is the process of understanding and controlling changes to system requirements

42

Requirements Engineering Process

5. Requirements Management (Planning)

Requirements identification Each requirement must be uniquely identified

A change management process Assess the impact and cost of change

Traceability policies Define the relationship between requirements

CASE tool support

43

Good Requirements

ExplanationCharacteristic

Everything the software is supposed to do and responses of the software to all classes of input data are specified in the SRS

Complete

The requirement does not contradict any other requirement Consistent

Every requirement in the SRS represents something required in the final system.

Correct

The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document. Every requirement has one and only one interpretation.

Unambiguous

There is a cost effective method that can check whether the final software meets the requirement.

Verifiable