7/31/2019 Lecture 04 2

1/35

Software Requirements

Presented By

Dr. Shazzad Hosain

7/31/2019 Lecture 04 2

2/35

Objectives

Importance of Requirement Engineering To introduce the concepts of user and system

requirements

To describe functional and non-functional

requirements To explain how software requirements may be

organised in a requirements document

7/31/2019 Lecture 04 2

3/35

Topics covered

Functional and non-functional requirements User requirements

System requirements

Interface specification

The software requirements document

7/31/2019 Lecture 04 2

4/35

SoftwareA Risky Business

Business as usual is not working.

Source: Standish Report, 1994

1. All based on waterfalllifecycle.

2. 53% cost almost 200%of original estimate.

3. Estimated $81 billionspent on failed U.S.projects in 1995.

7/31/2019 Lecture 04 2

5/35

Faulty Assumption 1:Requirements can be Fairly Accurate

Applied Software Measurement, Capers Jones, 1997. Based on6,700 systems.

7/31/2019 Lecture 04 2

6/35

Faulty Assumption 2:Requirements are Stable

The market changesconstantly.

The technology changes.

The goals of the stakeholders change.

7/31/2019 Lecture 04 2

7/35

Understanding Requirements

Factors on challenged software projects

7/31/2019 Lecture 04 2

8/35

The Cost of Change

An AT&T study indicated that, on average,

7/31/2019 Lecture 04 2

9/35

Requirement Change vs. Cost

7/31/2019 Lecture 04 2

10/35

Requirements engineering

The process of establishing the services that thecustomer requires from a system and the constraintsunder which it operates and is developed.

The requirements themselves are the descriptions of

the system services and constraints that aregenerated during the requirements engineeringprocess.

7/31/2019 Lecture 04 2

11/35

What is a requirement?

It may range from a high-level abstract statement of aservice or of a system constraint to a detailedmathematical functional specification.

This is inevitable as requirements may serve a dualfunction May be the basis for a bid for a contract - therefore must

be open to interpretation;

May be the basis for the contract itself - therefore must bedefined in detail;

Both these statements may be called requirements.

7/31/2019 Lecture 04 2

12/35

Requirements abstraction (Davis)

If a company wishes to let a contract for a large software development project, it must define its needs in asufficiently abstract way that a solution is not pre-defined. The requirements must be written so that severalcontractors can bid for the contract, offering, perhaps, different ways of meeting the client organisationsneeds. Once a contract has been awarded, the contractor must write a system definition for the client in

more detail so that the client understands and can validate what the software will do. Both of thesedocuments may be called the requirements documentfor the system.

7/31/2019 Lecture 04 2

13/35

Types of requirement

User requirements Statements in natural language plus diagrams of the

services the system provides and its operationalconstraints. Written for customers.

System requirements

A structured document setting out detailed descriptionsof the systems functions, services and operational

constraints. Defines what should be implemented somay be part of a contract between client and contractor.

7/31/2019 Lecture 04 2

14/35

Definitions and specifications

1. The softw are m ust provid e a means of representing and

1. accessing e xternal files cr ea ted b y o ther tools .

1.1 The user should b e pr ovid ed with facilities to defin e the ty pe o f

1.2 external fi les .

1.2 Each e xternal file type ma y have an associa ted to ol w hich ma y be

1.2 appli ed t o t he file .

1.3 Each e xternal file type ma y be r epr esented as a specific icon on

1.2 the user s d isplay.

1.4 Facilities should be pr ovided for the icon r epresenting an

1.2 external file type to be defin ed b y the user .1.5 When a user selects an icon r epr esenting an e xternal file, the

1.2 effect o f that se lecti on is t o apply t he tool associated with the typ e of

1.2 the external fil e to the fi le represented by the selected icon.

User requir ement defini tio n

System requir emen ts specification

7/31/2019 Lecture 04 2

15/35

Requirements readers

7/31/2019 Lecture 04 2

16/35

7/31/2019 Lecture 04 2

17/35

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 may be high-level

statements of what the system should do butfunctional system requirements should describe thesystem services in detail.

7/31/2019 Lecture 04 2

18/35

The LIBSYS system

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

Users can search for, download and print thesearticles for personal study.

7/31/2019 Lecture 04 2

19/35

Examples of functional requirements

The user shall be able to search either all of the initialset of databases or select a subset from it.

The system shall provide appropriate viewers for theuser 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 tothe accounts permanent storage area.

7/31/2019 Lecture 04 2

20/35

Requirements imprecision

Problems arise when requirements are not preciselystated.

Ambiguous requirements may be interpreted indifferent ways by developers and users.

Consider the term appropriate viewers User intention - special purpose viewer for each different

document type;

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

7/31/2019 Lecture 04 2

21/35

Requirements completeness and consistency

In principle, requirements should be both complete andconsistent.

Complete

They should include descriptions of all facilities required.

Consistent

There should be no conflicts or contradictions in thedescriptions of the system facilities.

In practice, it is impossible to produce a complete andconsistent requirements document.

7/31/2019 Lecture 04 2

22/35

Non-functional requirements

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

Process requirements may also be specified

mandating a particular CASE system, programminglanguage or development method.

Non-functional requirements may be more critical thanfunctional requirements. If these are not met, thesystem is useless.

7/31/2019 Lecture 04 2

23/35

Non-functional classifications

Product requirements Requirements which specify that the delivered product must behave

in a particular way e.g. execution speed, reliability, etc.

Organisational requirements

Requirements which are a consequence of organisational policies

and procedures e.g. process standards used, implementationrequirements, etc.

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

system and its development process e.g. interoperability

requirements, legislative requirements, etc.

7/31/2019 Lecture 04 2

24/35

Non-functional requirement types

Performance

requir em ents

Spa ce

re quir ements

Usa bility

requir ements

Efficiency

requir em ents

Re lia bility

re quir ements

Porta bility

requir em ents

Inte ro pe r ab ility

requir em ents

Ethical

requir ements

Legislative

requir em ents

Implementa tion

requir em ents

Standar ds

requir em ents

Delivery

requir em ents

Safety

requir em ents

Privacy

re quir ements

Product

re quir ements

Organisational

requir em ents

External

requir ements

Non-functionalrequir em ents

7/31/2019 Lecture 04 2

25/35

Non-functional requirements examples

Product requirement8.1 The user interface for LIBSYS shall be implemented as simple HTML

without frames or Java applets.

Organisational requirement

9.3.2 The system development process and deliverable documents shall

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

External requirement7.6.5 The system shall not disclose any personal information about

customers apart from their name and reference number to the operators ofthe system.

7/31/2019 Lecture 04 2

26/35

Goals and requirements

Non-functional requirements may be very difficult to stateprecisely and imprecise requirements may be difficult toverify.

Goal A general intention of the user such as ease of use.

Verifiable non-functional requirement A statement using some measure that can be objectively tested.

Goals are helpful to developers as they convey theintentions of the system users.

7/31/2019 Lecture 04 2

27/35

Examples

A system goal The system should be easy to use by experienced controllers and

should be organised in such a way that user errors are minimised.

A verifiable non-functional requirement Experienced controllers shall be able to use all the system functions

after a total of two hours training. After this training, the averagenumber of errors made by experienced users shall not exceed twoper day.

7/31/2019 Lecture 04 2

28/35

Requirements measures

Property Me asure

Speed Processed transactions/second

User/Event response time

Screen refresh time

Size M Bytes

Number of ROM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failure

Probability of unavailability

Rate of failure occurrence

Availability

Robustness T ime to restart after failure

Percentage of events causing failureProbability of data corruption on failure

Portability Percent age of target dependent st atements

Number of target systems

7/31/2019 Lecture 04 2

29/35

Requirements interaction Conflicts between different non-functional

requirements are common in complex systems.

Spacecraft system To minimise weight, the number of separate chips in the

system should be minimised.

To minimise power consumption, lower power chipsshould be used.

However, using low power chips may mean that morechips have to be used. Which is the most criticalrequirement?

7/31/2019 Lecture 04 2

30/35

Domain requirements

Derived from the application domain and describesystem characteristics and features that reflect thedomain.

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

computations.

If domain requirements are not satisfied, the systemmay be unworkable.

7/31/2019 Lecture 04 2

31/35

Library system domain requirements

There shall be a standard user interface to alldatabases which shall be based on the Z39.50standard.

Because of copyright restrictions, some documentsmust be deleted immediately on arrival. Depending on

the users requirements, these documents will eitherbe printed locally on the system server for manuallyforwarding to the user or routed to a network printer.

7/31/2019 Lecture 04 2

32/35

Domain requirements problems

Understandability Requirements are expressed in the language of the

application domain;

This is often not understood by software engineersdeveloping the system.

Implicitness

Domain specialists understand the area so well that they donot think of making the domain requirements explicit.

7/31/2019 Lecture 04 2

33/35

Assignments or Project, 20%

Decide Group Formation Decide on Project

7/31/2019 Lecture 04 2

34/35

References

Chapter 5 of Software Engineering -- by IanSommerville, 6th Edition

7/31/2019 Lecture 04 2

35/35

Questions?