11

Software RequirementsSoftware Requirements

Descriptions and Descriptions and specifications of a specifications of a system system

22

ObjectivesObjectives To introduce the concepts of user and To introduce the concepts of user and

system requirementssystem requirements To describe functional and non-To describe functional and non-

functional requirementsfunctional requirements To explain two techniques for To explain two techniques for

describing system requirementsdescribing system requirements To explain how software requirements To explain how software requirements

may be organised in a requirements may be organised in a requirements documentdocument

33

Topics coveredTopics covered Functional and non-functional Functional and non-functional

requirementsrequirements User requirementsUser requirements System requirementsSystem requirements The software requirements documentThe software requirements document

44

Requirements engineeringRequirements engineering The process of establishing the services The process of establishing the services

that the customer requires from a that the customer requires from a system and the constraints under system and the constraints under which it operates and is developedwhich it operates and is developed

The requirements themselves are the The requirements themselves are the descriptions of the system services and descriptions of the system services and constraints that are generated during constraints that are generated during the requirements engineering processthe requirements engineering process

55

What is a requirement?What is a requirement? It may range from a high-level abstract It may range from a high-level abstract

statement of a service or of a system constraint statement of a service or of a system constraint to a detailed mathematical functional to a detailed mathematical functional specificationspecification

This is inevitable as requirements may serve a This is inevitable as requirements may serve a dual functiondual function• May be the basis for a bid for a contract - therefore May be the basis for a bid for a contract - therefore

must be open to interpretationmust be open to interpretation• May be the basis for the contract itself - therefore May be the basis for the contract itself - therefore

must be defined in detailmust be defined in detail• Both these statements may be called requirementsBoth these statements may be called requirements

66

Types of requirementTypes of requirement User requirementsUser requirements

• Statements in natural language plus Statements in natural language plus diagrams of the services the system diagrams of the services the system provides and its operational constraints. provides and its operational constraints. Written for customersWritten for customers

System requirementsSystem requirements• A structured document setting out detailed A structured document setting out detailed

descriptions of the system services. Written descriptions of the system services. Written as a contract between client and contractoras a contract between client and contractor

Software specificationSoftware specification• A detailed software description which can A detailed software description which can

serve as a basis for a design or serve as a basis for a design or implementation. Written for developersimplementation. Written for developers

77

Definitions and specificationsDefinitions and specifications

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

1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.

Requirements definition

Requirements specification

88

Requirements readersRequirements readersClient managersSystem end-usersClient engineersContractor managersSystem architects

System end-usersClient engineersSystem architectsSoftware developers

Client engineers (perhaps)System architectsSoftware developers

User requirements

System requirements

Software designspecification

99

Functional and non-functional requirementsFunctional and non-functional requirements

Functional requirementsFunctional requirements• Statements of services the system should provide, how Statements of services the system should provide, how

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

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

system such as timing constraints, constraints on the system such as timing constraints, constraints on the development process, standards, etc.development process, standards, etc.

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

the system and that reflect characteristics of that domainthe system and that reflect characteristics of that domain

1010

Functional requirementsFunctional requirements Describe functionality or system servicesDescribe functionality or system services Depend on the type of software, Depend on the type of software,

expected users and the type of system expected users and the type of system where the software is usedwhere the software is used

Functional user requirements may be Functional user requirements may be high-level statements of what the system high-level statements of what the system should do but functional system should do but functional system requirements should describe the system requirements should describe the system services in detailservices in detail

1111

Examples of functional requirementsExamples of functional requirements

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

The system shall provide appropriate The system shall provide appropriate viewers for the user to read documents in viewers for the user to read documents in the document store. the document store.

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

1212

Requirements imprecisionRequirements imprecision Problems arise when requirements are not Problems arise when requirements are not

precisely statedprecisely stated Ambiguous requirements may be Ambiguous requirements may be

interpreted in different ways by developers interpreted in different ways by developers and usersand users

Consider the term ‘appropriate viewers’Consider the term ‘appropriate viewers’• User intention - special purpose viewer for each User intention - special purpose viewer for each

different document typedifferent document type• Developer interpretation - Provide a text viewer Developer interpretation - Provide a text viewer

that shows the contents of the documentthat shows the contents of the document

1313

Requirements completeness and Requirements completeness and consistencyconsistency

In principle requirements should be both complete In principle requirements should be both complete

and consistentand consistent CompleteComplete

• They should include descriptions of all facilities requiredThey should include descriptions of all facilities required

ConsistentConsistent• There should be no conflicts or contradictions in the There should be no conflicts or contradictions in the

descriptions of the system facilitiesdescriptions of the system facilities

In practice, it is impossible to produce a complete In practice, it is impossible to produce a complete

and consistent requirements documentand consistent requirements document

1414

Non-functional requirementsNon-functional requirements

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

Process requirements may also be specified Process requirements may also be specified mandating a particular CASE system, mandating a particular CASE system, programming language or development methodprogramming language or development method

Non-functional requirements may be more Non-functional requirements may be more critical than functional requirements. If these are critical than functional requirements. If these are not met, the system is uselessnot met, the system is useless

1515

Non-functional classificationsNon-functional classifications Product requirementsProduct requirements

• Requirements which specify that the delivered product Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, must behave in a particular way e.g. execution speed, reliability, etc.reliability, etc.

Organisational requirementsOrganisational requirements• Requirements which are a consequence of organisational Requirements which are a consequence of organisational

policies and procedures e.g. process standards used, policies and procedures e.g. process standards used, implementation requirements, etc.implementation requirements, etc.

External requirementsExternal requirements• Requirements which arise from factors which are external Requirements which arise from factors which are external

to the system and its development process e.g. to the system and its development process e.g. interoperability requirements, legislative requirements, etc.interoperability requirements, legislative requirements, etc.

1616

Non-functional requirement typesNon-functional requirement types

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

1717

Non-functional requirements examplesNon-functional requirements examples Product requirementProduct requirement

• 4.C.8 It shall be possible for all necessary communication 4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the between the APSE and the user to be expressed in the standard Ada character setstandard Ada character set

Organisational requirementOrganisational requirement• 9.3.2 The system development process and deliverable 9.3.2 The system development process and deliverable

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

External requirementExternal requirement• 7.6.5 The system shall not disclose any personal 7.6.5 The system shall not disclose any personal

information about customers apart from their name and information about customers apart from their name and reference number to the operators of the systemreference number to the operators of the system

1818

Goals and requirementsGoals and requirements Non-functional requirements may be very Non-functional requirements may be very

difficult to state precisely and imprecise difficult to state precisely and imprecise requirements may be difficult to verify. requirements may be difficult to verify.

GoalGoal• A general intention of the user such as ease of useA general intention of the user such as ease of use

Verifiable non-functional requirementVerifiable non-functional requirement• A statement using some measure that can be A statement using some measure that can be

objectively testedobjectively tested

Goals are helpful to developers as they convey Goals are helpful to developers as they convey the intentions of the system usersthe intentions of the system users

1919

ExamplesExamples

A system goalA system goal

• The system should be easy to use by experienced The system should be easy to use by experienced

controllers and should be organised in such a way that controllers and should be organised in such a way that

user errors are minimised.user errors are minimised.

A verifiable non-functional requirementA verifiable non-functional requirement

• Experienced controllers shall be able to use all the Experienced controllers shall be able to use all the

system functions after a total of two hours training. system functions after a total of two hours training.

After this training, the average number of errors made After this training, the average number of errors made

by experienced users shall not exceed two per day.by experienced users shall not exceed two per day.

2020

Requirements measuresRequirements measuresProperty MeasureSpeed Processed transactions/second

User/Event response timeScreen refresh time

Size K BytesNumber of RAM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

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

Portability Percentage of target dependent statementsNumber of target systems

2121

Requirements interactionRequirements interaction Conflicts between different non-functional Conflicts between different non-functional

requirements are common in complex requirements are common in complex systemssystems

Spacecraft systemSpacecraft system• To minimise weight, the number of separate chips To minimise weight, the number of separate chips

in the system should be minimisedin the system should be minimised• To minimise power consumption, lower power To minimise power consumption, lower power

chips should be usedchips should be used• However, using low power chips may mean that However, using low power chips may mean that

more chips have to be used. Which is the most more chips have to be used. Which is the most critical requirement?critical requirement?

2222

Domain requirementsDomain requirements

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

May be new functional requirements, May be new functional requirements, constraints on existing requirements constraints on existing requirements or define specific computationsor define specific computations

If domain requirements are not If domain requirements are not satisfied, the system may be satisfied, the system may be unworkableunworkable

2323

Library system domain Library system domain requirementsrequirements

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

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

2424

Domain requirements problemsDomain requirements problems

UnderstandabilityUnderstandability• Requirements are expressed in the Requirements are expressed in the

language of the application domainlanguage of the application domain• This is often not understood by software This is often not understood by software

engineers developing the systemengineers developing the system ImplicitnessImplicitness

• Domain specialists understand the area Domain specialists understand the area so well that they do not think of making so well that they do not think of making the domain requirements explicitthe domain requirements explicit

2525

User requirementsUser requirements

Should describe functional and non-Should describe functional and non-functional requirements so that they functional requirements so that they are understandable by system users are understandable by system users who don’t have detailed technical who don’t have detailed technical knowledgeknowledge

User requirements are defined using User requirements are defined using natural language, tables and natural language, tables and diagramsdiagrams

2626

Problems with natural languageProblems with natural language

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

document difficult to readdocument difficult to read Requirements confusionRequirements confusion

• Functional and non-functional Functional and non-functional requirements tend to be mixed-uprequirements tend to be mixed-up

Requirements amalgamationRequirements amalgamation• Several different requirements may be Several different requirements may be

expressed togetherexpressed together

2727

Database requirementDatabase requirement

4.A.5 The database shall support the generation and control of configuration objects; that is, objects which are themselves groupings of other objects in the database. The configuration control facilities shall allow access to the objects in a version group by the use of an incomplete name.

2828

Editor grid requirementEditor grid requirement

2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, 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 editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.

2929

Requirement problemsRequirement problems Database requirements includes both Database requirements includes both

conceptual and detailed informationconceptual and detailed information• Describes the concept of configuration control Describes the concept of configuration control

facilitiesfacilities• Includes the detail that objects may be accessed Includes the detail that objects may be accessed

using an incomplete nameusing an incomplete name Grid requirement mixes three different kinds of Grid requirement mixes three different kinds of

requirementrequirement• Conceptual functional requirement (the need for a Conceptual functional requirement (the need for a

grid)grid)• Non-functional requirement (grid units)Non-functional requirement (grid units)• Non-functional UI requirement (grid switching)Non-functional UI requirement (grid switching)

3030

Guidelines for writing Guidelines for writing requirementsrequirements

Invent a standard format and use it for Invent a standard format and use it for all requirementsall requirements

Use language in a consistent way. Use Use language in a consistent way. Use shall for mandatory requirements, shall for mandatory requirements, should for desirable requirementsshould for desirable requirements

Use text highlighting to identify key Use text highlighting to identify key parts of the requirementparts of the requirement

Avoid the use of computer jargonAvoid the use of computer jargon

3131

System requirementsSystem requirements

More detailed specifications of user More detailed specifications of user requirementsrequirements

Serve as a basis for designing the Serve as a basis for designing the systemsystem

May be used as part of the system May be used as part of the system contractcontract

System requirements may be System requirements may be expressed using system modelsexpressed using system models

3232

Requirements and designRequirements and design

In principle, requirements should state what In principle, requirements should state what the system should do and the design should the system should do and the design should describe how it does thisdescribe how it does this

In practice, requirements and design are In practice, requirements and design are inseparableinseparable• A system architecture may be designed to A system architecture may be designed to

structure the requirementsstructure the requirements• The system may inter-operate with other The system may inter-operate with other

systems that generate design requirementssystems that generate design requirements• The use of a specific design may be a domain The use of a specific design may be a domain

requirementrequirement

3333

Structured language Structured language specificationsspecifications

A limited form of natural language A limited form of natural language may be used to express may be used to express requirementsrequirements

This removes some of the problems This removes some of the problems resulting from ambiguity and resulting from ambiguity and flexibility and imposes a degree of flexibility and imposes a degree of uniformity on a specificationuniformity on a specification

Often bast supported using a forms-Often bast supported using a forms-based approachbased approach

3434

Form-based specificationsForm-based specifications Definition of the function or entityDefinition of the function or entity Description of inputs and where they Description of inputs and where they

come fromcome from Description of outputs and where they Description of outputs and where they

go togo to Indication of other entities requiredIndication of other entities required Pre and post conditions (if appropriate)Pre and post conditions (if appropriate) The side effects (if any)The side effects (if any)

3535

PDL-based requirements definitionPDL-based requirements definition Requirements may be defined operationally using a Requirements may be defined operationally using a

language like a programming language but with language like a programming language but with more flexibility of expressionmore flexibility of expression

Most appropriate in two situationsMost appropriate in two situations• Where an operation is specified as a sequence of actions Where an operation is specified as a sequence of actions

and the order is importantand the order is important• When hardware and software interfaces have to be When hardware and software interfaces have to be

specifiedspecified Disadvantages areDisadvantages are

• The PDL may not be sufficiently expressive to define The PDL may not be sufficiently expressive to define domain conceptsdomain concepts

• The specification will be taken as a design rather than a The specification will be taken as a design rather than a specificationspecification

3636

PDL disadvantagesPDL disadvantages

PDL may not be sufficiently expressive PDL may not be sufficiently expressive to express the system functionality in to express the system functionality in an understandable wayan understandable way

Notation is only understandable to Notation is only understandable to people with programming language people with programming language knowledgeknowledge

The requirement may be taken as a The requirement may be taken as a design specification rather than a design specification rather than a model to help understand the systemmodel to help understand the system

3737

Interface specificationInterface specification Most systems must operate with other Most systems must operate with other

systems and the operating interfaces must systems and the operating interfaces must be specified as part of the requirementsbe specified as part of the requirements

Three types of interface may have to be Three types of interface may have to be defineddefined• Procedural interfacesProcedural interfaces• Data structures that are exchangedData structures that are exchanged• Data representationsData representations

Formal notations are an effective technique Formal notations are an effective technique for interface specificationfor interface specification

3838

The requirements documentThe requirements document The requirements document is the The requirements document is the

official statement of what is required official statement of what is required of the system developersof the system developers

Should include both a definition and Should include both a definition and a specification of requirementsa specification of requirements

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

3939

Users of a Users of a requirements requirements

documentdocument

Use the requirements todevelop validation tests forthe system

Use the requirementsdocument to plan a bid forthe system and to plan thesystem development process

Use the requirements tounderstand what system is tobe developed

System testengineers

Managers

System engineers

Specify the requirements andread them to check that theymeet their needs. Theyspecify changes to therequirements

System customers

Use the requirements to helpunderstand the system andthe relationships between itsparts

Systemmaintenance

engineers

4040

Requirements document requirementsRequirements document requirements

Specify external system behaviourSpecify external system behaviour Specify implementation constraintsSpecify implementation constraints Easy to changeEasy to change Serve as reference tool for maintenanceServe as reference tool for maintenance Record forethought about the life cycle Record forethought about the life cycle

of the system i.e. predict changesof the system i.e. predict changes Characterise responses to unexpected Characterise responses to unexpected

eventsevents

4141

IEEE requirements standardIEEE requirements standard IntroductionIntroduction General descriptionGeneral description Specific requirementsSpecific requirements AppendicesAppendices IndexIndex This is a generic structure that must This is a generic structure that must

be instantiated for specific systemsbe instantiated for specific systems

4242

Requirements document structureRequirements document structure

IntroductionIntroduction GlossaryGlossary User requirements definitionUser requirements definition System architectureSystem architecture System requirements specificationSystem requirements specification System modelsSystem models System evolutionSystem evolution AppendicesAppendices IndexIndex

4343

Key pointsKey points Requirements set out what the system should do Requirements set out what the system should do

and define constraints on its operation and and define constraints on its operation and

implementationimplementation Functional requirements set out services the Functional requirements set out services the

system should providesystem should provide Non-functional requirements constrain the system Non-functional requirements constrain the system

being developed or the development processbeing developed or the development process User requirements are high-level statements of User requirements are high-level statements of

what the system should dowhat the system should do

4444

Key pointsKey points

User requirements should be written in natural User requirements should be written in natural language, tables and diagramslanguage, tables and diagrams

System requirements are intended to System requirements are intended to communicate the functions that the system communicate the functions that the system should provideshould provide

System requirements may be written in System requirements may be written in structured natural language, a PDL or in a structured natural language, a PDL or in a formal languageformal language

A software requirements document is an A software requirements document is an agreed statement of the system requirementsagreed statement of the system requirements