Chapter 4 – Requirements Engineering

Chapter 4 – RequirementsEngineeringSummary1

Topics covered Functional and non-functional requirementsThe software requirements documentRequirements specificationRequirements engineering processesRequirements elicitation and analysisRequirements validationRequirements management2

Requirements engineering The process of establishing the services thatthe customer requires from a system and theconstraints under which it operates and isdeveloped. The requirements themselves are thedescriptions of the system services andconstraints that are generated during therequirements engineering process.3

What is a requirement? It may range from a high-level abstract statementof a service or of a system constraint to a detailedmathematical functional specification. This is inevitable as requirements may serve adual function– May be the basis for a bid for a contract - thereforemust be open to interpretation;– May be the basis for the contract itself - thereforemust be defined in detail;– Both these statements may be called requirements.4

Requirements abstraction (Davis)“If a company wishes to let a contract for a large software developmentproject, it must define its needs in a sufficiently abstract way that asolution is not pre-defined. The requirements must be written so thatseveral contractors can bid for the contract, offering, perhaps, differentways of meeting the client organization’s needs. Once a contract hasbeen awarded, the contractor must write a system definition for theclient in more detail so that the client understands and can validate whatthe software will do. Both of these documents may be called therequirements document for the system.”5

Types of requirement User requirements– Statements in natural language plus diagrams ofthe services the system provides and itsoperational constraints. Written for customers. System requirements– A structured document setting out detaileddescriptions of the system’s functions, servicesand operational constraints. Defines what shouldbe implemented so may be part of a contractbetween client and contractor.6

User and system requirements7

Readers of different types ofrequirements specification8

Functional and non-functionalrequirements Functional requirements– Statements of services the system should provide, how the systemshould react to particular inputs and how the system should behave inparticular situations.– May state what the system should not do. Non-functional requirements– Constraints on the services or functions offered by the system such astiming constraints, constraints on the development process, standards,etc.– Often apply to the system as a whole rather than individual features orservices. Domain requirements– Constraints on the system from the domain of operation9

Functional requirements Describe functionality or system services. Depend on the type of software, expectedusers and the type of system where thesoftware is used. Functional user requirements may be highlevel statements of what the system shoulddo. Functional system requirements shoulddescribe the system services in detail.10

Functional requirements for the MHC-PMS A user shall be able to search theappointments lists for all clinics. The system shall generate each day, for eachclinic, a list of patients who are expected toattend appointments that day. Each staff member using the system shall beuniquely identified by his or her 8-digitemployee number.11

Requirements imprecision Problems arise when requirements are notprecisely stated. Ambiguous requirements may be interpreted indifferent ways by developers and users. Consider the term ‘search’ in requirement 1– User intention – search for a patient name across allappointments in all clinics;– Developer interpretation – search for a patient namein an individual clinic. User chooses clinic then search.12

Requirements completeness andconsistency 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.13

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 specifiedmandating a particular IDE, programming languageor development method. Non-functional requirements may be more criticalthan functional requirements. If these are not met,the system may be useless.14

Types of nonfunctional requirement15

Non-functional requirementsimplementation Non-functional requirements may affect the overallarchitecture of a system rather than the individualcomponents.– For example, to ensure that performance requirements aremet, you may have to organize the system to minimizecommunications between components. A single non-functional requirement, such as a securityrequirement, may generate a number of relatedfunctional requirements that define system servicesthat are required.– It may also generate requirements that restrict existingrequirements.16

Non-functional classifications Product requirements– Requirements which specify that the delivered product must behave ina particular way e.g. execution speed, reliability, etc. Organisational requirements– Requirements which are a consequence of organisational policies andprocedures e.g. process standards used, implementationrequirements, etc. External requirements– Requirements which arise from factors which are external to thesystem and its development process e.g. interoperabilityrequirements, legislative requirements, etc.17

Examples of nonfunctionalrequirements in the MHC-PMSProduct requirementThe MHC-PMS shall be available to all clinics during normal workinghours (Mon–Fri, 0830–17.30). Downtime within normal working hoursshall not exceed five seconds in any one day.Organizational requirementUsers of the MHC-PMS system shall authenticate themselves usingtheir health authority identity card.External requirementThe system shall implement patient privacy provisions as set out inHStan-03-2006-priv.18

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 the intentionsof the system users.19

Usability requirements The system should be easy to use by medical staffand should be organized in such a way that usererrors are minimized. (Goal) Medical staff shall be able to use all the systemfunctions after four hours of training. After thistraining, the average number of errors made byexperienced users shall not exceed two per hour ofsystem use. (Testable non-functional requirement)20

Metrics for specifying ssed transactions/secondUser/event response timeScreen refresh timeSizeMbytesNumber of ROM chipsEase of useTraining timeNumber of help framesReliabilityMean time to failureProbability of unavailabilityRate of failure occurrenceAvailabilityRobustnessTime to restart after failurePercentage of events causing failureProbability of data corruption on failurePortabilityPercentage of target dependent statementsNumber of target systems21

Domain requirements The system’s operational domain imposesrequirements on the system.– For example, a train control system has to takeinto account the braking characteristics indifferent weather conditions. Domain requirements be new functionalrequirements, constraints on existing requirementsor define specific computations. If domain requirements are not satisfied, the systemmay be unworkable.22

Train protection system This is a domain requirement for a train protectionsystem: The deceleration of the train shall be computed as:– Dtrain Dcontrol Dgradient– where Dgradient is 9.81ms2 * compensatedgradient/alpha and where the values of 9.81ms2 /alphaare known for different types of train. It is difficult for a non-specialist to understand theimplications of this and how it interacts with otherrequirements.23

Domain requirements problems Understandability– Requirements are expressed in the language ofthe application domain;– This is often not understood by softwareengineers developing the system. Implicitness– Domain specialists understand the area so wellthat they do not think of making the domainrequirements explicit.24

Key points Requirements for a software system set out what thesystem should do and define constraints on itsoperation and implementation. Functional requirements are statements of the servicesthat the system must provide or are descriptions ofhow some computations must be carried out. Non-functional requirements often constrain thesystem being developed and the development processbeing used. They often relate to the emergent properties of thesystem and therefore apply to the system as a whole.25

The software requirements document The software requirements document is theofficial statement of what is required of thesystem developers. Should include both a definition of userrequirements and a specification of thesystem requirements. It is NOT a design document. As far aspossible, it should set of WHAT the systemshould do rather than HOW it should do it.26

Agile methods and requirements Many agile methods argue that producing arequirements document is a waste of time asrequirements change so quickly. The document is therefore always out of date. Methods such as XP use incremental requirementsengineering and express requirements as ‘user stories’(discussed in Chapter 3). This is practical for business systems but problematicfor systems that require a lot of pre-delivery analysis(e.g. critical systems) or systems developed by severalteams.27

Users of a requirements document28

Requirements document variability Information in requirements document dependson type of system and the approach todevelopment used. Systems developed incrementally will, typically,have less detail in the requirements document. Requirements documents standards have beendesigned e.g. IEEE standard. These are mostlyapplicable to the requirements for large systemsengineering projects.29

The structure of a requirementsdocumentChapterDescriptionPrefaceThis should define the expected readership of the document and describeits version history, including a rationale for the creation of a new versionand a summary of the changes made in each version.IntroductionThis should describe the need for the system. It should briefly describe thesystem’s functions and explain how it will work with other systems. Itshould also describe how the system fits into the overall business orstrategic objectives of the organization commissioning the software.GlossaryThis should define the technical terms used in the document. You shouldnot make assumptions about the experience or expertise of the reader.Userrequirements Here, you describe the services provided for the user. The nonfunctionaldefinitionsystem requirements should also be described in this section. Thisdescription may use natural language, diagrams, or other notations that areunderstandable to customers. Product and process standards that must befollowed should be specified.System architectureThis chapter should present a high-level overview of the anticipated systemarchitecture, showing the distribution of functions across system modules.Architectural components that are reused should be highlighted.30