requirements engineering u establishing what the customer ...bmitchell/course/mcs451/ch_4.pdf ·...

©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 4 Slide

Requirements Engineering

u Establishing what the customerrequires from a softwaresystem


Objectivesu To introduce the notion of requirements

engineeringu To explain why requirements at different levels

of detail are neededu To describe how the system requirements

document may be organisedu To describe the requirements validation processu To explain why requirements evolve during the

lifetime of a system


Topics coveredu The requirements engineering processu The software requirements documentu Requirements validationu Requirements evolution


Requirements engineeringu The process of establishing the services that the

customer requires from a system and theconstraints under which it operates and isdeveloped

u Requirements may be functional or non-functional• Functional requirements describe system services or functions• Non-functional requirements is a constraint on the system or on

the development process


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

of a service or of a system constraint to a detailedmathematical functional specification

u This is inevitable as requirements may serve adual function• 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 be

defined in detail• Both these statements may be called requirements


Requirements definition/specificationu Requirements definition

• A statement in natural language plus diagrams of the servicesthe system provides and its operational constraints. Written forcustomers

u Requirements specification• A structured document setting out detailed descriptions of the

system services. Written as a contract between client andcontractor

u Software specification• A detailed software description which can serve as a basis for a

design or implementation. Written for developers


Definitions and specifications1. The software must provide a means of representing and1. accessing external fi les created by other tools.

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

Requirements definition

Requirements specification


Requirements readersClient managersSystem end-usersClient engineersContractor managersSystem architects

System end-usersClient engineersSystem architectsSoftware developers

Client engineers (perhaps)System architectsSoftware developers

Requirementsdefinition

Requirementsspecification

Softwarespecification


Wicked problemsu Most large software systems address wicked

problemsu Problems which are so complex that they can

never be fully understood and whereunderstanding develops during the systemdevelopment

u Therefore, requirements are normally bothincomplete and inconsistent


Reasons for inconsistencyu Large software systems must improve the current

situation. It is hard to anticipate the effects thatthe new system will have on the organisation

u Different users have different requirements andpriorities. There is a constantly shiftingcompromise in the requirements

u System end-users and organisations who pay forthe system have different requirements

u Prototyping is often required to clarifyrequirements


The requirements engineering processu Feasibility study

• Find out if the current user needs be satisfied given the availabletechnology and budget?

u Requirements analysis• Find out what system stakeholders require from the system

u Requirements definition• Define the requirements in a form understandable to the

customer

u Requirements specification• Define the requirements in detail


The RE processFeasibi li ty

studyRequirements

analysis

Requirementsdefini tion

Requirementsspecification

Feasibi li tyreport

Systemmodels

Defini tion ofrequirements

Speci fication ofrequirements

Requirementsdocument


The requirements documentu The requirements document is the official

statement of what is required of the systemdevelopers

u Should include both a definition and aspecification of requirements

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


Requirements document requirementsu Specify external system behaviouru Specify implementation constraintsu Easy to changeu Serve as reference tool for maintenanceu Record forethought about the life cycle of the

system i.e. predict changesu Characterise responses to unexpected events


Requirements document structureu Introduction

• Describe need for the system and how it fits with businessobjectives

u Glossary• Define technical terms used

u System models• Define models showing system components and relationships

u Functional requirements definition• Describe the services to be provided


Requirements document structureu Non-functional requirements definition

• Define constraints on the system and the development process

u System evolution• Define fundamental assumptions on which the system is based

and anticipated changes

u Requirements specification• Detailed specification of functional requirements

u Appendices• System hardware platform description• Database requirements (as an ER model perhaps)

u Index


Requirements validationu Concerned with demonstrating that the

requirements define the system that the customerreally wants

u Requirements error costs are high so validation isvery important• Fixing a requirements error after delivery may cost up to 100

times the cost of fixing an implementation error

u Prototyping (discussed in Chapter 8) is animportant technique of requirements validation


Requirements checkingu Validity. Does the system provide the functions

which best support the customer’s needs?u Consistency. Are there any requirements

conflicts?u Completeness. Are all functions required by the

customer included?u Realism. Can the requirements be implemented

given available budget and technology


Requirements reviewsu Regular reviews should be held while the

requirements definition is being formulatedu Both client and contractor staff should be

involved in reviewsu Reviews may be formal (with completed

documents) or informal. Good communicationsbetween developers, customers and users canresolve problems at an early stage


Review checksu Verifiability. Is the requirement realistically

testable?u Comprehensibility. Is the requirement properly

understood?u Traceability. Is the origin of the requirement

clearly stated?u Adaptability. Can the requirement be changed

without a large impact on other requirements?


Automated consistency checking

Requirementsdatabase

Requirementsanalyser

Requirementsproblem report

Requirementsprocessor

Requirementsin a formal language


Requirements evolutionu Requirements always evolve as a better

understanding of user needs is developed and asthe organisation’s objectives change

u It is essential to plan for change in therequirements as the system is being developedand used


Requirements evolution

Changedunderstanding

of problem

Initialunderstanding

of problem

Changedrequirements

Initialrequirements

Time


Requirements classesu Enduring requirements. Stable requirements

derived from the core activity of the customerorganisation. E.g. a hospital will always havedoctors, nurses, etc. May be derived from domainmodels

u Volatile requirements. Requirements whichchange during development or when the system isin use. In a hospital, requirements derived fromhealth-care policy


Classification of requirementsu Mutable requirements

• Requirements that change due to the system’s environment

u Emergent requirements• Requirements that emerge as understanding of the system

develops

u Consequential requirements• Requirements that result from the introduction of the computer

system

u Compatibility requirements• Requirements that depend on other systems or organisational

processes


Requirements document changesu The requirements document should be organised

so that requirements changes can be madewithout extensive rewriting

u External references should be minimised and thedocument sections should be as modular aspossible

u Changes are easiest when the document iselectronic. Lack of standards for electronicdocuments make this difficult


Controlled evolution

Systemimplementation V1




Requirementsdocument V1

Requirementschange



Requirementschange

Requirements and systeminconsistent

Requirements and systemconsistent


Key pointsu It is very difficult to formulate a complete and

consistent requirements specificationu A requirements definition, a requirements

specification and a software specification areways of specifying software for different types ofreader

u The requirements document is a description forcustomers and developers


Key pointsu Requirements errors are usually very expensive to

correct after system deliveryu Reviews involving client and contractor staff are

used to validate the system requirementsu Stable requirements are related to core activities

of the customer for the softwareu Volatile requirements are dependent on the

context of use of the system

requirements engineering u establishing what the customer ...bmitchell/course/mcs451/ch_4.pdf ·...

Documents