Lecture 5: Requirements Engineering Dr Valentina Plekhanova University of Sunderland, UK cs0vpl/SE-Com185.htm

Lecture 5Lecture 5:: Requirements EngineeringRequirements Engineering

Dr Valentina PlekhanovaDr Valentina Plekhanova

University of Sunderland, UKUniversity of Sunderland, UK

http://www.cet.sunderland.ac.uk/~cs0vpl/SE-Com185.htmhttp://www.cet.sunderland.ac.uk/~cs0vpl/SE-Com185.htm

Lecture 5 Valentina Plekhanova 2

What is a Requirement?What is a Requirement? [Pfleeger, 1998]

A requirementrequirement is a feature of the system or a description of something the system is capable of doing in order to fulfil the system’s purpose.


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

of a service or of a system constraint to a detailed mathematical functional specification.

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.


Wicked Problems Wicked Problems [[Sommerville; Vliet]Sommerville; Vliet]

Originally this term was defined by Rittel and Webber, in 1973.

A “wicked problemwicked problem" is a complex problem, i.e. this problem is very difficult to define and/or identify (e.g. define related entities, definitive problems specification).

In general, no one can accurately predict where/when we can expect the problem and what effect it will have on the software production, etc.

The problem can be tackled after it has happened.


Wicked ProblemsWicked Problems Most large software systems address

wicked problems. Problems which are so complex that they

can never be fully understood and where understanding develops during the system development.

Therefore, requirements are normally both incomplete and inconsistent.


A Stakeholder ..!!!A Stakeholder ..!!! The notion of stakeholderstakeholder is used to refer

to anyone who should have some influence on the system requirements, e.g. end-users, engineers, business managers, domain experts, etc.


Some Reasons for Some Reasons for InconsistencyInconsistency Different stakeholders have different requirements and they may define these in different ways.

There is a constantly shifting compromise in the requirements...

Different people may negotiate different parts.


Some Reasons Some Reasons for Incompletenessfor Incompleteness Requirements can be interpreted differently. Many requirements can be identified clearly only

after some experience with the system. Too many details would need to be specified. Customer asks for too little. The world changes. It is difficult to define the level of precision in the

requirements statements. Informal language (e.g. natural language) does not

help in requirements statements.


Requirements: Functional Requirements: Functional andand Non-FunctionalNon-Functional

Functional requirementsFunctional requirements describe system services or functions.

Non-functional requirementsNon-functional requirements is a constraint on the system or on the development process, e.g. timing constraints, standards, etc.


Non-Functional RequirementsNon-Functional Requirements

Process Process Requirements: Requirements:

standards, standards, delivery,etc.delivery,etc.

Non-Functional Non-Functional Requirements Requirements

Efficiency Efficiency Requirements:Requirements: efficiency, reliability, efficiency, reliability, portability,usability portability,usability

External External Requirements:Requirements: ethical, ethical, legislativelegislative


Requirements EngineeringRequirements Engineering The process of establishing the services

that

the customer requires from a system … under the constraints with which it operates

... and is developed!


The Requirements Engineering ProcessThe Requirements Engineering Process

Feasibility StudyFeasibility Study

Requirements AnalysisRequirements Analysis

Requirements DefinitionRequirements Definition

Requirements SpecificationRequirements Specification

11

22

33

44

Requirements ValidationRequirements Validation

55


1. Feasibility study1. Feasibility study Find out if the current user needs can be

satisfied given the available technology and budget?

A definition of the problemsproblems. Alternative solutionsAlternative solutions and their expected

benefitsbenefits. Required resources, costs, timeRequired resources, costs, time and

delivery datesdates for each alternative solution.

11


2. Requirements Analysis2. Requirements Analysis Find out what system stakeholdersstakeholders require

from the system.

22


3. Requirements Definition 3. Requirements Definition 4. Requirements Specification4. Requirements Specification

……. . The ultimate purposeultimate purpose of the requirements-related

activities is: To understand the goals of the system; To document the requirements to be met; To specify the qualities required of the software

solution: functionality, performance, reliability, etc.


3. Requirements Definition3. Requirements Definition A statement in natural language plus diagrams of the A statement in natural language plus diagrams of the

services the system provides and its operational services the system provides and its operational constraintsconstraints.

Define the requirements in a form understandable to the customer.

It represent an understanding between the customer and developer of what the customer needs/wants.

It is usually written jointly by the customer and developer.

Written for customers.Written for customers.

33


4. Requirements Specification4. Requirements Specification A structured document setting out detailed

descriptions of the system services. Define the requirements in detail. It uses technical terms to define the system

services: a very precise, even mathematical description – but it must be understandable by the client.

Written as a contract between client and Written as a contract between client and contractor.contractor.

44


Software SpecificationSoftware Specification A detailed software description which can

serve as a basis for a design or implementation.

Written for developers.Written for developers.


An Example of: An Example of: Requirements Document StructureRequirements Document Structure (1)

IntroductionIntroduction Describe need for the system and how it fits with

business objectives.

GlossaryGlossary Define technical terms used.

System modelsSystem models Define models showing (high level architectural)

system components and relationships.


Requirements Document Structure Requirements Document Structure (cont 2)

Non-functional requirements definitionNon-functional requirements definition Define constraints on the system and the

development process.

System evolutionSystem evolution Define fundamental assumptions on which the

system is based and anticipated changes.

Requirements specificationRequirements specification Detailed specification of functional requirements.


Requirements Document Structure Requirements Document Structure (cont 3)

AppendicesAppendices System hardware platform description. Database requirements (as an ER

model perhaps). IndexIndex

o More examples of requirements document can be More examples of requirements document can be found in [Pfleeger, 1998; Sommerville]found in [Pfleeger, 1998; Sommerville]


5. Requirements Validation5. Requirements Validation

Concerned with demonstrating the requirements define the system that the customer really wants.

Requirements error costs are high so validation is very important ...

Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

Prototyping is an important technique of requirements validation.

55


Requirements CheckingRequirements Checking

ValidityValidity – Does the system provide the functions which best support the customer’s needs?

ConsistencyConsistency – Are there any requirements conflicts?

CompletenessCompleteness – Are all functions required by the customer included?

RealismRealism – Can the requirements be implemented given available budget and technology?


Key PointsKey Points It is very difficult to formulate a complete and consistent

requirements specification. A requirements definition, a requirements specification and a

software specification are ways of specifying software for different types of reader.

The requirements document is a description for customers and developers.

Requirements errors are usually very expensive to correct after system delivery.

Reviews involving client and contractor staff are used to validate the system requirements.

Stable requirements are related to core activities of the customer for the software.

Volatile requirements are dependent on the context of use for the system.


Week 8:Week 8: 24.04.2003-28.04.2003 24.04.2003-28.04.2003Project Control SessionProject Control Session Tutorial Time: 10 minutes for each Team Tutorial Time: 10 minutes for each Team Students will present project file, particularly

ScheduleSchedule, plus any project documentationdocumentation. Students will describe where they are in the

project and any problems encountered. During the discussion reviewers will ask to see

evidence of deliverables for any tasks that are complete to determine whether they have in fact been done.

Documents

Lecture 5: Requirements Engineering Dr Valentina Plekhanova University of Sunderland, UK cs0vpl/SE-Com185.htm