Requirement engineering process

Requirements Engineering Processes

Loganathan RLoganathan R

Objectives

• To describe the principal requirementsengineering activities and their relationships

• To introduce techniques for requirementselicitation and analysiselicitation and analysis

• To describe requirements validation and the roleof requirements reviews

• To discuss the role of requirements managementin support of other requirements engineeringprocesses

2Prof. Loganathan R, CSE,HKBKCE

Requirements engineering processes

• The goal of RE Process is to create & maintain asystem requirements documents.

• Includes 4 High level RE Sub-processes:– Feasibility study : usefulness to the business ;

– Elicitation and analysis : discovering requirements;– Elicitation and analysis : discovering requirements;

– Specification: conversion of requirement into some standardform;

– Validation : check the requirements which defines the systemthat the customer wants;


The requirements engineering process

FeasibilityStudy

RequirementsElicitation and

Analysis

RequirementsSpecification

RequirementsFeasibility


RequirementsValidation

FeasibilityReport

SystemModels

User and SystemRequirements

RequirementsDocument

Alternative perspective of RE Process

Requirementsspecification

System requirementsspecification and

modeling

User requirementsspecification

Business requirementsspecification

Spiral Model of RE Process


Requirementsvalidation

Requirementselicitation

Systemrequirements

elicitationUser

requirementselicitation

Prototyping

Feasibilitystudy

Reviews

System requirementsdocument

Feasibility studies

• A feasibility study decides whether or not theproposed system is worthwhile.

• A short focused study that checks

– If the system contributes to organisational objectives;– If the system contributes to organisational objectives;

– If the system can be implemented using currenttechnology, within given cost and schedule constraints;

– If the system can be integrated with other systems thatare already in place.


Feasibility study implementation• Feasibility study involves information assessment (what is

required), information collection and report writing.

• Questions for people in the organisation for informationassessment and collection:– What if the system wasn’t implemented?

– What are current process problems?– What are current process problems?

– How will the proposed system help?

– What will be the integration problems?

– Is new technology needed? What skills?

– What facilities must be supported by the proposed system?

• Feasibility study report should make a recommendation about thedevelopment to continue or not.


Requirements elicitation and analysis• Involves technical staff working with customers to find out about

the application domain, the services that the system should provideand the system’s operational constraints.

• May involve end-users, managers, engineers involved inmaintenance, domain experts, trade unions, etc. These are calledstakeholders.

• Eliciting & understanding stakeholder requirement is difficult due to• Eliciting & understanding stakeholder requirement is difficult due tothe following reasons:• Stakeholders don’t know what they really want except in most general.

• Stakeholders express requirements in their own terms.

• Different stakeholders may have deferent requirements.

• Organisational and political factors may influence the system requirements.

• The requirements change during the analysis process. New stakeholders mayemerge and the business environment change.


E&A Process activities• Requirements discovery

– Interacting with stakeholders to discover their requirements.Domain requirements are also discovered at this stage.

• Requirements classification and organisation– Group related requirements and organises them into coherent

clusters.clusters.

• Prioritisation and negotiation– Prioritising requirements and finding and resolving

requirements conflicts.

• Requirements documentation– Requirements are documented and input into the next round of

the spiral.


The requirements elicitation & analysis Process

RequirementsClassification &

Organization

RequirementsPrioritization &

negotiation


RequirementsDocumentation

RequirementsDiscovery

Requirements discovery• The process of gathering information about the proposed and

existing systems and distilling the user and systemrequirements from this information.

• Sources of information include documentation, systemstakeholders and the specifications of similar systems.

• Approaches & Techniques of requirements discovery are:• Approaches & Techniques of requirements discovery are:

– Viewpoints(approach)

– Interviewing

– Scenario

– Use-cases

– ethnography


Example : ATM stakeholders• Bank customers – who receive services

• Representatives of other banks – who have reciprocal agreementsfor ATM usage

• Bank branch managers –who obtain management information

• Counter staff – who involved in day-to-day running of system

• Database administrators - who responsible for integrating system• Database administrators - who responsible for integrating systemwith customers database

• Bank Security managers

• The Bank’s Marketing department

• Hardware and software maintenance engineers

• Banking regulators Who ensures system conforms to bankingregulations


Viewpoints• Recognizes multiple perspectives and provides framework for

discovering conflicts in the requirements proposed by differentstakeholders

• Viewpoints(VP) are used as a way of classifying Stakeholders andother sources of requirements.

• There are 3 generic types of VP:

• Interactor viewpoints• Interactor viewpoints– People or other systems that interact directly with the system. In an ATM, the customer’s

and the account database are interactor VPs.

• Indirect viewpoints– Stakeholders who do not use the system themselves but who influence the requirements.

In an ATM, management and security staff are indirect viewpoints.

• Domain viewpoints– Domain characteristics and constraints that influence the requirements. In an ATM, an

example would be standards for inter-bank communications.


Viewpoint identification• Identify viewpoints using following more specific VP

types:– Providers and receivers of system services;

– Systems that interact directly with the system beingspecified;specified;

– Regulations and standards that apply to the system;

– Sources of business and non-functional requirements.

– Engineers who have to develop and maintain the system;

– Marketing and other business viewpoints.


LIBSYS viewpoint hierarchy

InteractorIndirect

All VPs

Domain


ArticleprovidersFinance

Librarymanager

LibrarystaffUsers Classification

systemUI

standards

ExternalStaffStudents CataloguersSystem

managers

Interviewing• Used for getting an overall understanding of what

stakeholders do, how they interact with systemand difficulties they face with current system

• In formal or informal interviewing, the RE teamputs questions to stakeholders about the systemputs questions to stakeholders about the systemthat they use and the system to be developed.

• There are two types of interview– Closed interviews where a pre-defined set of questions

are answered.

– Open interviews where there is no pre-defined agendaand a range of issues are explored with stakeholders.


Interviews in practice• Normally a mix of closed and open-ended interviewing.

• Interviews are good for getting an overall understandingof what stakeholders do and how they might interact withthe system.

• Interviews are not good for understanding domainrequirementsrequirements– Requirements engineers cannot understand specific domain

terminology;

– Some domain knowledge is so familiar that people find it hardto articulate or think that it isn’t worth articulating.


Effective interviewers Characteristics

• Interviewers should be open-minded, willing tolisten to stakeholders and should not have pre-conceived ideas about the requirements.

• They should prompt the interviewee with a• They should prompt the interviewee with aquestion or a proposal and should not simplyexpect them to respond to a question such as‘what do you want’.


Scenarios

• Scenarios are real-life examples of how a system canbe used.

• They should include– A description of what the system & user expect when the

scenario starts;scenario starts;

– A description of the normal flow of events in the scenario;

– A description of what can go wrong and how this ishandled;

– Information about other concurrent activities;

– A description of the state when the scenario finishes.


LIBSYS scenario…Initial assumption: The user has logged on to the LIBSYS system and haslocated the journal containing the copy of the article.

Normal: The user selects the article to be copied. He or she is thenprompted by the system to either provide subscriber information for thejournal or to indicate how they will pay for the article. Alternative paymentmethods are by credit card or by quoting an organisational accountnumber.number.

The user is then asked to fill in a copyright form that maintains details ofthe transaction and they then submit this to the LIBSYS system.

The copyright form is checked and, if OK, the PDF version of the article isdownloaded to the LIBSYS working area on the user’s computer and theuser is informed that it is available. The user is asked to select a printer anda copy of the article is printed. If the article has been flagged as ‘print-only’it is deleted from the user’s system once the user has confirmed thatprinting is complete.


LIBSYS scenario…What can go wrong: The user may fail to fill in the copyright form correctly.In this case, the form should be re-presented to the user for correction. Ifthe resubmitted form is still incorrect then the user’s request for the articleis rejected.

The payment may be rejected by the system. The user’s request for thearticle is rejected.

The article download may fail. Retry until successful or the user terminatesthe session.

It may not be possible to print the article. If the article is not flagged as‘print-only’ then it is held in the LIBSYS workspace. Otherwise, the article isdeleted and the user’s account credited with the cost of the article.

Other activities: Simultaneous downloads of other articles.

System state on completion: User is logged on. The downloaded article hasbeen deleted from LIBSYS workspace if it has been flagged as print -only.


Use cases

• Use-cases are a scenario based technique in theUML which identify the actors in an interactionand which describe the interaction itself.

• A set of use cases should describe all possible• A set of use cases should describe all possibleinteractions with the system.

• Sequence diagrams may be used to add detail touse-cases by showing the sequence of eventprocessing in the system.


Simple Use-case for Article printing• Actors is stick figures, each class of interaction is

named ellipse.


Article printing

Use cases for library system

Article printing

Article search

Library


Article printing

User administration

Supplier Catalogue services

LibraryUser

LibraryStaff

System interactions for article Printing

User

item:Article

CopyrightFormForm

request

complete

Myworkspace:Workspace

myPrinter:Printer

request

return


copyright OK

deliver

article OK

print send

confirminform

delete

Ethnography• Ethnography is an observational technique used to

understand social and organisational requirements.

• A social scientists spends a considerable time observingand analysing how people actually work.

• People do not have to explain or articulate their work.• People do not have to explain or articulate their work.

• Social and organisational factors of importance may beobserved.

• Ethnographic studies have shown that work is usuallyricher and more complex than suggested by simplesystem models.


Focused ethnography

• Developed in a project studying the air trafficcontrol process

• Combines ethnography with prototyping

• Prototype development results in unanswered• Prototype development results in unansweredquestions which focus the ethnographic analysis.

• The problem with ethnography is that it studiesexisting practices which may have some historicalbasis which is no longer relevant.


Ethnography and prototyping

DebriefingMeetings

EthnographicAnalysis

FocusedEthnography


PrototypeEvaluation

Generic SystemDevelopment

SystemPrototyping

Ethnography discovers 2 types ofrequirements

• Requirements that are derived from the way thatpeople actually work rather than the way I whichprocess definitions suggest that they ought toprocess definitions suggest that they ought towork.

• Requirements that are derived from cooperationand awareness of other people’s activities.


Requirements validation

• Concerned with demonstrating that therequirements define the system that the customerreally wants.

• Requirements error costs are high so validation is• Requirements error costs are high so validation isvery important

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


Requirements checking

• Validity: Does the system provide the functions whichbest support the customer’s needs?

• Consistency: Are there any requirements conflicts?

• Completeness: Are all functions required by the customer• Completeness: Are all functions required by the customerincluded?

• Realism: Can the requirements be implemented givenavailable budget and technology

• Verifiability: Can the requirements be checked?


Requirements validation techniques

• Requirements reviews– Systematic manual analysis of the requirements.

• Prototyping– Using an executable model of the system to check– Using an executable model of the system to check

requirements.

• Test-case generation– Developing tests for requirements to check testability.

– If test is difficult or impossible to design for therequirement means it is difficult to implement thatrequirement


Requirements reviews

• Regular reviews should be held while therequirements definition is being formulated.

• Both client and contractor staff should be involvedin reviews.in reviews.

• Reviews may be formal (with completeddocuments) or informal. Good communicationsbetween developers, customers and users canresolve problems at an early stage.


Review checks

• Verifiability: Is the requirement realisticallytestable?

• Comprehensibility: Is the requirement properlyunderstood?understood?

• Traceability: Is the origin of the requirementclearly stated?

• Adaptability: Can the requirement be changedwithout a large impact on other requirements?


Requirements management

• Requirements management is the process of managingchanging requirements during the requirementsengineering process and system development.

• Requirements are inevitably incomplete and inconsistent– New requirements emerge during the process as business needs– New requirements emerge during the process as business needs

change and a better understanding of the system is developed;– Different viewpoints have different requirements and these are

often contradictory.


Requirements change

• The priority of requirements from differentviewpoints changes during the developmentprocess.

• System customers may specify requirements from• System customers may specify requirements froma business perspective that conflict with end-userrequirements.

• The business and technical environment of thesystem changes during its development.


Requirements evolution

ChangedUnderstanding of

Problem

InitialUnderstanding of

Problem


Time

ChangedRequirements

InitialRequirements

Enduring and volatile requirements

• Enduring requirements: Stable requirementsderived from the core activity of the customerorganisation. E.g. a hospital will always havedoctors, nurses, etc. May be derived from domainmodelsmodels

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


Requirements classificationRequirementType

Description

Mutablerequirements

Requirements that change because of changes to the environment inwhich the organisation is operating. For example, in hospital systems,the funding of patient care may change and thus require differenttreatment information to be collected.

EmergentRequirements that emerge as the customer's understanding of thesystem develops during the system development. The design process


Emergentrequirements

system develops during the system development. The design processmay reveal new emergent requirements.

Consequentialrequirements

Requirements that result from the introduction of the computersystem. Introducing the computer system may change theorganisations processes and open up new ways of working whichgenerate new system requirements

Compatibilityrequirements

Requirements that depend on the particular systems or businessprocesses within an organisation. As these change, the compatibilityrequirements on the commissioned or delivered system may also haveto evolve.

Requirements management planning

• During the requirements engineering process, youhave to plan:– Requirements identification

• How requirements are individually identified;– A change management process

• The process followed when analysing a requirements change;• The process followed when analysing a requirements change;– Traceability policies

• The amount of information about requirements relationshipsthat is maintained;

– CASE tool support• The tool support required to help manage requirements

change;


Traceability• Traceability is concerned with the relationships between

requirements, their sources and the system design

• Source traceability

– Links from requirements to stakeholders who proposed theserequirements;requirements;

• Requirements traceability

– Links between dependent requirements;

• Design traceability

– Links from the requirements to the design;


A traceability matrix

Req. id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

1.1 D R

1.2 D D D

1.3 R R


1.3 R R

2.1 R D D

2.2 D

2.3 R D

3.1 R

3.2 R

CASE tool support

• Requirements storage

– Requirements should be managed in a secure, managed datastore.

• Change management

– The process of change management is a workflow processwhose stages can be defined and information flow betweenthese stages partially automated.

• Traceability management

– Automated retrieval of the links between requirements.


Requirements change management

• Should apply to all proposed changes to therequirements.

• Principal stages– Problem analysis: Discuss requirements problem and– Problem analysis: Discuss requirements problem and

propose change;

– Change analysis and costing: Assess effects of changeon other requirements;

– Change implementation: Modify requirementsdocument and other documents to reflect change.


Change management

Problem Analysisand ChangeSpecification

ChangeImplementation

ChangeAnalysis and

costing

IdentifiedProblem

RevisedRequirements


Specification costing

Technology

Requirement engineering process