software requirements.ppt

7/26/2019 software requirements.ppt

1/31


2/31

To introduce the concepts of user andsystem requirements

To describe functional and non-functional

requirements To explain how software requirements may

be organised in a requirements document


3/31

Functional and non-functionalrequirements

User requirements

System requirements Interface specication

The software requirements document


4/31

The process of establishing the servicesthat the customer requires from a systemand the constraints under which it

operates and is developed The requirements themselves are the

descriptions of the system services andconstraints that are generated during the

requirements engineering process


5/31

It may range from a high-level abstractstatement of a service or of a systemconstraint to a detailed mathematicalfunctional specication

This is inevitable as requirements may serve adual function !ay be the basis for a bid for a contract - therefore

must be open to interpretation" !ay be the basis for the contract itself - therefore

must be dened in detail" #oth these statements may be called

requirements


6/31

If a company wishes to let a contract for a large software development project, it

must define its needs in a sufficiently abstract way that a solution is not pre-defined.

The requirements must be written so that several contractors can bid for the contract,

offering, perhaps, different ways of meeting the client organisations needs. Once acontract 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 these documents may be called the requirements documentfor the

system.


7/31

User requirements Statements in natural language plus diagrams of

the services the system provides and itsoperational constraints $ritten for customers

System requirements % structured document setting out detailed

descriptions of the system&s functions' servicesand operational constraints (enes what shouldbe implemented so may be part of a contractbetween client and contractor


8/31

) The software must provide a means ofrepresenting and

)accessing external les created by other tools

)) The user should be provided with facilities to dene the type of)*external les

)* +ach external le type may have an associated tool which may be)*applied to the le

), +ach external le type may be represented as a specic icon on)*the user&s display

) Facilities should be provided for the icon representing an

)*external le type to be dened by the user). $hen a user selects an icon representing an external le' the)*e/ect of that selection is to apply the tool associated with the t

)*the external le to the le represented by the selected icon

User requirement denition

System requirements specication


9/31

0lient managersSystem end-users0lient engineers

0ontractor managersSystem architects

System end-users0lient engineers

System architectsSoftware developers

0lient engineers 1perhaps2System architectsSoftware developers

Userrequirements

System

requirements

Software design

specication


10/31

Functional requirements Statements of services the system should provide' how the

system should react to particular inputs and how the systemshould behave in particular situations

3on-functional requirements

constraints on the services or functions o/ered by the systemsuch as timing constraints' constraints on the developmentprocess' standards' etc

(omain requirements 4equirements that come from the application domain of the

system and that re5ect characteristics of that domain


11/31

(escribe functionality or system services (epend 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 shoulddo but functional system requirements

should describe the system services indetail


12/31

% library system that provides a singleinterface to a number of databases ofarticles in di/erent libraries

Users can search for' download and printthese articles for personal study


13/31

The user shall be able to search either all of theinitial set of databases or select a subset from it

The system shall provide appropriate viewers forthe user to read documents in the documentstore

+very order shall be allocated a unique identier164(+47I(2 which the user shall be able to copy

to the account&s permanent storage area


14/31

8roblems arise when requirements are notprecisely stated

%mbiguous requirements may be interpretedin di/erent ways by developers and users

0onsider the term 9appropriate viewers& User intention - special purpose viewer for each

di/erent document type"

(eveloper interpretation - 8rovide a text viewerthat shows the contents of the document


15/31

In principle' requirements should be both complete andconsistent

0omplete

They should include descriptions of all facilities

required 0onsistent

There should be no con5icts or contradictionsin the descriptions of the system facilities

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


16/31

These dene system properties and constraintseg reliability' response time and storagerequirements 0onstraints are I:6 devicecapability' system representations' etc

8rocess requirements may also be speciedmandating a particular 0%S+ system'programming language or development method

3on-functional requirements may be morecritical than functional requirements If theseare not met' the system is useless


17/31

8roduct requirements 4equirements which specify that the delivered product must

behave in a particular way eg execution speed' reliability' etc

6rganisational requirements 4equirements which are a consequence of organisational policies

and procedures eg process standards used' implementationrequirements' etc

+xternal requirements 4equirements which arise from factors which are external to the

system and its development process eg interoperability

requirements' legislative requirements' etc


18/31

8erformance

requirements

Space

requirements

Usability

requirements

+fciency

requirements

4eliability

requirements

8ortability

requirements

Interoperability

requirements

+thical

requirements

;egislative

requirements

Implementation

requirements

Standards

requirements

(elivery

requirements

Safety

requirements

8ri vacy

requirements

8roduct

requirements

6rganisational

requirements

+xternal

requirements

3on-functionalrequirements


19/31

8roduct requirementT!; without frames or ?ava applets

6rganisational requirement@,* The system development process and deliverable

documents shall conform to the process and deliverablesdened in A=B0o-S8-ST%3-@.

+xternal requirementCD. The system shall not disclose any personal information

about customers apart from their name and reference number

to the operators of the system


20/31

3on-functional requirements may be very diEcult tostate precisely and imprecise requirements may bediEcult to verify

oal % general intention of the user such as ease of use

Geriable non-functional requirement % statement using some measure that can be obHectively tested

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


21/31

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 verifable non-unctional requirement +xperienced controllers shall be able to use all the system

functions after a total of two hours training %fter this training' theaverage number of errors made by experienced users shall notexceed two per day


22/31

Property Measure

Speed Processed transactions/second

User/Event response time

Screen refresh time

Size M Bytes

Number of ROM chips

Ease of use Trainin timeNumber of he!p frames

Re!iabi!ity Mean time to fai!ure

Probabi!ity of unavai!abi!ity

Rate of fai!ure occurrence

"vai!abi!ity

Robustness Time to restart after fai!ure

Percentae of events causin fai!ureProbabi!ity of data corruption on fai!ure

Portabi!ity Percentae of taret dependent statements

Number of taret systems


23/31

0on5icts between di/erent non-functionalrequirements are common in complexsystems

Spacecraft system

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

To minimise power consumption' lower powerchips should be used

>owever' using low power chips may mean thatmore chips have to be used $hich is the mostcritical requirement


24/31

(erived from the application domain anddescribe system characteristics andfeatures that re5ect the domain

(omain requirements be new functionalrequirements' constraints on existingrequirements or dene speciccomputations

If domain requirements are not satised'the system may be unworJable


25/31

There shall be a standard user interface toall databases which shall be based on theB,@.K standard

#ecause of copyright restrictions' some

documents must be deleted immediately onarrival (epending on the user&srequirements' these documents will eitherbe printed locally on the system server for

manually forwarding to the user or routed toa networJ printer


26/31

The deceleration of the train shall becomputed asL

(trainM (controlN (gradient

where (gradient is @


27/31

Understandability 4equirements are expressed in the language of

the application domain"

This is often not understood by softwareengineers developing the system

Implicitness (omain specialists understand the area so well

that they do not thinJ of maJing the domainrequirements explicit


28/31

Should describe functional and non-functional requirements in such a way thatthey are understandable by system userswho don&t have detailed technicalJnowledge

User requirements are dened usingnatural language' tables and diagrams as

these can be understood by all users


29/31

;acJ of clarity 8recision is diEcult without maJing the

document diEcult to read

4equirements confusion Functional and non-functional requirements

tend to be mixed-up

4equirements amalgamation

Several di/erent requirements may beexpressed together


30/31

Invent a standard format and use it for allrequirements

Use language in a consistent way Use shall

for mandatory requirements' should fordesirable requirements

Use text highlighting to identify Jey partsof the requirement

%void the use of computer Hargon


31/31

System requirements are intended tocommunicate the functions that the systemshould provide

% software requirements document is anagreed statement of the systemrequirements

The I+++ standard is a useful starting point

for dening more detailed specicrequirements standards

Documents

software requirements.ppt