Software requirements

Software Requirements

Loganathan RLoganathan R

Objectives

• To introduce the concepts of user requirementsand system requirements

• To describe functional and non-functionalrequirementsrequirements

• To explain how software requirements may beorganised in a requirements document

2Prof. Loganathan R., CSE, HKBKCE

Requirements engineering

• The process of finding out, analysing,documenting, and checking the services that thecustomer requires from a system and itsoperational constraints is called RE.operational constraints is called RE.

• Requirement may range from a high-level abstractstatement of a service or of a system constraint toa detailed mathematical functional specification.


Requirements abstraction (Davis)

“If a company wishes to let a contract for a large softwaredevelopment 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,contractors can bid for the contract, offering, perhaps,different ways of meeting the client organisation’s needs.Once a contract has been awarded, the contractor mustwrite a system definition for the client in more detail sothat the client understands and can validate what thesoftware will do. Both of these documents may be calledthe requirements document for the system.”


Types of requirement

• User requirements (high level abstract requirements)

– Statements in natural language plus diagrams of whatservices the system provides and its operationalconstraints. Written for customers.

• System requirements (description of what system should do)

– A structured document(also called functional specification)setting out detailed descriptions of the system’s functions,services and operational constraints. Defines what shouldbe implemented so may be part of a contract betweenclient and contractor.


Definitions and specifications

1.1 On making a request for a document from LIBSYS, the requestor shall bepresented with a form that records details of user and the request made

1. LIBSYS shall keep track of all data required by copyright licensingagencies in INDIA and elsewhere1.

User requirement Definition

System Requirements Specification

Prof. Loganathan R., CSE, HKBKCE 6

presented with a form that records details of user and the request made

1.2 LIBSYS request forms shall be stored on the system for 5 years from thedate of the request

1.3 All LIBSYS request forms must be indexed by user, by the name of thematerial requested and by the supplier of the request

1.4 LIBSYS shall maintain a log of all requests that have been made to thesystem.

1.5 For material where authors lending rights apply, loan details shall be sentmonthly to copyright licensing agencies that have registered with LIBSYS.

.

.

.

.

Requirements readers

UserRequirements

Client ManagersSystem End-UsersClient EngineersContractor ManagersSystem Architect


System Architect

System End-UsersClient EngineersSystem ArchitectSoftware Developers

SystemRequirements

Functional and non-functional requirements

• Software system requirements are classified as:

• 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(and sometimes what itshould NOT do).should NOT do).

• Non-functional requirements– constraints on the services or functions offered by the system

such as timing constraints, constraints on the developmentprocess, standards, etc. Apply to the system as whole.

• Domain requirements– Requirements that come from the application domain of the

system and that reflect characteristics of that domain.8Prof. Loganathan R., CSE, HKBKCE

Functional requirements

• Describe what the system should do.

• Depend on the type of software, expected usersand the type of system where the software isused.used.

• Functional user requirements may be high-levelstatements of what the system should do butfunctional system requirements should describethe system services in detail, its i/o, exceptionsand so on.


Example: The LIBSYS system

• A library system that provides a single interface toa number of databases of articles in differentlibraries.

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


Examples of functional requirements of LIBSYS

• 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 documentthe user to read documents in the documentstore.

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


Requirements imprecision

• Problems arise when requirements are notprecisely stated.

• Ambiguous requirements may be interpreted indifferent ways by developers and users.different 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.


Requirements completeness and consistency

• In principle, requirements should be bothcomplete and consistent.

• Completeness

– All services required by the user should be defined.– All services required by the user should be defined.

• Consistent

– Requirements should NOT have conflicts orcontradictions in the descriptions.

• In practice, it is impossible to produce a complete and consistentrequirements document.


Non-functional requirements

• Related to emergent properties and constraints .Emergent properties are reliability, response time,storage requirements and so on. Constraints areI/O device capability, data representations, etc.

• Process requirements may also be specified• Process requirements may also be specifiedmandating a particular CASE system, programminglanguage or development method.

• Non-functional requirements may be more criticalthan functional requirements. If these are notmet, the system is useless.


• Product requirements

– Specify product behaviour. E.g. execution speed, memoryrequired, reliability (failure rate), portability requirements,usability requirements, etc.

• Organisational requirements

Non-functional requirement types

• Organisational requirements

– Derived from customer and developer organisational policiesand procedures. e.g. process standards used, implementationrequirements, delivery requirements, etc.

• External requirements

– Derived from factors which are external to the system and itsdevelopment process e.g. interoperability requirements,legislative requirements, ethical requirements etc.


Non-functional requirement types

ProductRequirements

OrganisationalRequirements

ExternalRequirements

Non-functionalRequirements


PerformanceRequirements

SpaceRequirements

UsabilityRequirements

EfficiencyRequirements

ReliabilityRequirements

PortabilityRequirements

InteroperabilityRequirements

EthicalRequirements

LegislativeRequirements

ImplementationRequirements

StandardsRequirements

DeliveryRequirements

SafetyRequirements

PrivacyRequirements

LIBSYS Non-functional requirements

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

frames or Java applets.

• Organisational requirement9.3.2 The system development process and deliverable documents shall conform9.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 of the system.


Problems in non-functional requirements

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

• Goal

– A general intention of the user such as ease of use, recovery– A general intention of the user such as ease of use, recoveryfrom failure, etc.

• 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.


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– Experienced controllers shall be able to use all the system functions after a

total of two hours training. After this training, the average number of errorsmade by experienced users shall not exceed two per day.


Requirements MeasuresProperty Measure

SpeedProcessed transactions/secondUser/Event response timeScreen refresh time

SizeM BytesNumber of ROM chips

Ease of useTraining time


Ease of useTraining timeNumber of help frames

Reliability

Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

RobustnessTime to restart after failurePercentage of events causing failureProbability of data corruption on failure

PortabilityPercentage of target dependent statementsNumber of target systems

Requirements interaction

• Conflicts between different non-functionalrequirements are common in complex systems.

• Example :Spacecraft system– To minimise weight, the number of separate chips in– 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?


Domain requirements

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

• Domain requirements be new functional• Domain requirements be new functionalrequirements, constraints on existingrequirements or define specific computations.

• If domain requirements are not satisfied, thesystem may be unworkable.


Example of LIBSYS domain requirements

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

• Because of copyright restrictions, some• Because of copyright restrictions, somedocuments must be deleted immediately onarrival. Depending on the user’s requirements,these documents will either be printed locally onthe system server for manually forwarding to theuser or routed to a network printer.


Example : Train protection system• Computation of deceleration to stop the train:

The deceleration of the train shall be computed as:

Dtrain = Dcontrol + Dgradient

where D is 9.81ms2 * compensated gradient/alphawhere Dgradient is 9.81ms2 * compensated gradient/alphaand where the values of 9.81ms2 /alpha are known fordifferent types of train.

• Problem: Since it is written in application domainlanguage its difficult to understand by s/wengineers.


Domain requirements problems

• Understandability

– Requirements are expressed in the language of theapplication domain;

– This is often not understood by software engineers– This is often not understood by software engineersdeveloping the system.

• Implicitness

– Domain specialists understand the area so well thatthey do not think of making the domain requirementsexplicit.


User requirements

• Should describe functional and non-functionalrequirements in such a way that they areunderstandable by system users who don’t havedetailed technical knowledge.detailed technical knowledge.

• User requirements are defined using naturallanguage, tables and diagrams as these can beunderstood by all users.


Problems with natural language(UR)

• Lack of clarity– Precision is difficult without making the document

difficult to read.

• Requirements confusion• Requirements confusion– Functional and non-functional requirements tend to be

mixed-up.

• Requirements amalgamation– Several different requirements may be expressed

together.


A user requirement for accountingsystem in LIBSYS

4..5 LIBSYS shall provide a financial accountingsystem that maintains records of all paymentsmade by users of the system. System managersmade by users of the system. System managersmay configure this system so that regular usersmay receive discounted rates.


A user requirement for Editor grid in LIBSYS

2.6 Grid facilities To assist in the positioning of entities on adiagram, the user may turn on a grid in either centimetres orinches, via an option on the control panel. Initially, the grid is off.The grid may be turned on and off at any time during an editingThe grid may be turned on and off at any time during an editingsession and can be toggled between inches and centimetres atany time. A grid option will be provided on the reduce-to-fit viewbut the number of grid lines shown will be reduced to avoidfilling the smaller diagram with grid lines.


Requirement problems• Database requirements includes both conceptual and

detailed information– Describes the concept of a financial accounting system that is to

be included in LIBSYS;

– However, it also includes the detail that managers can configurethis system - this is unnecessary at this level.this system - this is unnecessary at this level.

• Grid requirement mixes three different kinds ofrequirement– Conceptual functional requirement is the need for a grid. It

presents rationale for this

– Non-functional requirement of grid units (inches/cm)

– Non-functional UI requirement grid switching(on/off)


Definition of an editor grid facility

• Grid requirements are rewritten to focus on theessential system feature

2.6.1 Grid facilitiesThe editor shall provide a grid facility where a matrix of horizontaland vertical lines provide a background to the editor window. Thisgrid shall be a passive grid where the alignment of entities is the user's


grid shall be a passive grid where the alignment of entities is the user'sresponsibility.

Rationale: A grid helps the user to create a tidy diagram with well-spaced entities. Although an active grid, where entities 'snap-to'grid lines can be useful, the positioning is imprecise. The user is thebest person to decide where entities should be positioned.

Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6Source: Ray Wilson, Glasgow Office

Guidelines for writing User Requirements

• Invent a standard format and use it for allrequirements.

• Use language in a consistent way. Use shall formandatory requirements, should for desirablemandatory requirements, should for desirablerequirements.

• Use text highlighting(Bold, Italic or Colour) toidentify key parts of the requirement.

• Avoid the use of computer jargon.


System requirements

• More detailed specifications of system functions,services and constraints than user requirements.

• They are intended to be a basis for designing thesystem.system.

• They may be incorporated into the systemcontract.

• Natural Language(NL) is often used to writesystem requirements specification as well as userrequirements.


Inseparable : Requirements and design

• In principle, requirements should state what thesystem should do and the design should describehow it does this.

• In practice, requirements and design areinseparableinseparable– A system architecture may be designed to structure the

requirements;– The system may inter-operate with other systems that

generate design requirements;– The use of a specific design may be a domain

requirement.


Problems with NL specification(Sys Req.)

• Ambiguity– The readers and writers of the requirement must

interpret the same words in the same way. NL isnaturally ambiguous so this is very difficult.

• Over-flexibility• Over-flexibility– The same thing may be said in a number of different

ways in the specification.

• Lack of modularisation– NL structures are inadequate to structure system

requirements.


Notations for requirements specification• These can be used as alternatives to NL specification

Notation Description

Structured naturallanguage

This approach depends on defining standard forms or templates to express therequirements specification.

Design descriptionlanguages

This approach uses a language like a programming language but with moreabstract features to specify the requirements by defining an operational modelof the system. This approach is not now widely used although it can be useful


of the system. This approach is not now widely used although it can be usefulfor interface specifications.

Graphical notations A graphical language, supplemented by text annotations is used to define thefunctional requirements for the system. An early example of such a graphicallanguage was SADT. Now, use-case descriptions and sequence diagrams arecommonly used .

Mathematicalspecifications

These are notations based on mathematical concepts such as finite-statemachines or sets. These unambiguous specifications reduce the argumentsbetween customer and contractor about system functionality. However, mostcustomers don’t understand formal specifications and are reluctant to accept itas a system contract.

Structured Language Specifications

• The freedom of the requirements writer is limitedby a predefined template for requirements.

• All requirements are written in a standard way.

• The terminology used in the description may be• The terminology used in the description may belimited.

• The advantage is that the most of theexpressiveness of natural language is maintainedbut a degree of uniformity is imposed on thespecification.


Form-based Approach

• One or more standard forms/templates aredesigned to express the requirements. It shouldinclude the following information.– Description of the function or entity.

– Description of inputs and where they come from.

– Description of outputs and where they go to.

– Indication of what other entities required.

– Description of action to be taken.

– Pre and post conditions what must be true before & after function call(ifappropriate).

– Description the side effects (if any) of the function.


Insulin Pump/Control Software/SRS/3.3.2

Function Compute insulin dose: Safe sugar level

Description Computes the dose of insulin to be delivered when the current measured sugar level isin the safe zone between 3 and 7 units

Inputs Current sugar reading (r2), the previous two readings (r0 and r1)

Source Current sugar reading from sensor. Other readings from memory.

Outputs CompDose – the dose in insulin to be delivered

Form-based specification Example

Outputs CompDose – the dose in insulin to be delivered

Destination Main control loop

Action CompDose is zero if the sugar level is stable or falling or if the level is increasing but therate of increase is decreasing. If the level is increasing and the rate of increase isincreasing, then CompDose is computed by dividing the difference between the currentsugar level and the previous level by 4 and rounding the result. If the result, is roundedto zero then CompDose is set to the minimum dose that can be delivered.

Requires Two previous readings so that the rate of change of sugar level can be computed.

Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin

Post-condition r0 is replaced by r1 then r1 is replaced by r2

Side-effects None39Prof. Loganathan R., CSE, HKBKCE

Tabular specification• Used to supplement natural language.

• Particularly useful when you have to define a number of possiblealternative courses of action.

• Example : Tabular specification of computation

Condition Action


Condition Action

Sugar level falling (r2 < r1) CompDose = 0

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate of increasedecreasing ((r2-r1)<(r1-r0))

CompDose = 0

Sugar level increasing and rate of increasestable or increasing. ((r2-r1) ≥ (r1-r0))

CompDose = round ((r2-r1)/4)If rounded result = 0 thenCompDose = MinimumDose

Graphical models

• Graphical models are most useful when you need to showhow state changes or where you need to describe asequence of actions.

• Example Sequence diagrams

• These show the sequence of events that take place during• These show the sequence of events that take place duringsome user interaction with a system.

• Read them from top to bottom to see the order of theactions that take place.

• Cash withdrawal from an ATM– Validate card : By checking the card number and user’s PIN

– Handle request : user requests are handled. Query database for withdrawal

– Complete transaction: return the card and deliver cash & receipt.41Prof. Loganathan R., CSE, HKBKCE

Sequence diagram of ATM withdrawal

Validate card

ATM Database

CardCard number

Card OKPIN request

PIN

Option menu

<<exception>>invalid card

Withdraw request Balance request


Withdraw request

Amount request

Amount

Balance request

Balance

<<exception>>Insufficient cash

Debit (amount)

Debit response

Card

Card removed

Cash

Cash removed

Receipt

Handle request

Completetransaction

Interface specification

• Most systems must operate with other systemsand the operating interfaces must be specified aspart of the requirements.

• Three types of interface may have to be defined– Procedural interfaces : ;– Procedural interfaces : APIs;

– Data structures : Passed from one subsystem to another

– Data representations (ordering of bits) : for existingsubsystem

• Formal notations(Program Design Language - PDL)are an effective technique for interfacespecification.


PDL interface description

interface PrintServer {// defines an abstract printer server// requires: interface Printer, interface PrintDoc// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;void print ( Printer p, PrintDoc d ) ;


void print ( Printer p, PrintDoc d ) ;void displayPrintQueue ( Printer p ) ;void cancelPrintJob (Printer p, PrintDoc d) ;void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;

} //PrintServer

The Software Requirements Document

• The requirements document is the officialstatement of what is required of the systemdevelopers.

• Should include both a definition of user• Should include both a definition of userrequirements and a specification of the systemrequirements.

• It is NOT a design document. As far as possible, itshould set of WHAT the system should do ratherthan HOW it should do it


Users of a requirements document

Use the requirements

document to plan a bid for

the system and to plan the

system development process

Managers

SystemCustomers

Specify the requirements and

read them to check that they

meet their needs. They

specify changes to the

requirements


System TestEngineers

Use the requirements to

develop validation tests for

the system

Use the requirements to

understand what system is to

be developed

SystemEngineers

SystemMaintenance

Engineers

Use the requirements to help

understand the system and

the relationships between itsparts

IEEE requirements standard• Defines a structure for a requirements document.

1. Introduction.1.1 Purpose of the requirements document

1.2 Scope of the product

1.3 Definition, acronyms & abbreviations

1.4 References

1.5 Overview of the remainder of the document

2. General description.2. General description.2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 General constraints

2.5 Assumptions & dependencies

3. Specific requirements.(covers functional, non-functional & interface requirements)

4. Appendices.

5. Index.


Requirements document structure• Organisation for a requirements document based on IEEE standard

– Preface : Defines expected readership, version history & changes in each version

– Introduction : Describes the needs of the system

– Glossary : Defines technical terms used in the document

– User requirements definition : Describes services provided & non-functional requirementsfunctional requirements

– System architecture : Presents high level overview of system

– System requirements specification : Describes functional & non-functional requirements in detail

– System models : Provides 1 or more system models

– System evolution : Describes anticipated changes

– Appendices

– Index48Prof. Loganathan R., CSE, HKBKCE

Date post:	15-Dec-2014
Category:	Education
Upload:	loganathan-ramasamy
View:	1,449 times
Download:	1 times

Software requirements

Education