Upload
loganathan-ramasamy
View
6.354
Download
4
Tags:
Embed Size (px)
DESCRIPTION
Requirement Engineering Process
Citation preview
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;
3Prof. Loganathan R, CSE,HKBKCE
The requirements engineering process
FeasibilityStudy
RequirementsElicitation and
Analysis
RequirementsSpecification
RequirementsFeasibility
4Prof. Loganathan R, CSE,HKBKCE
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
5Prof. Loganathan R, CSE,HKBKCE
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.
6Prof. Loganathan R, CSE,HKBKCE
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.
7Prof. Loganathan R, CSE,HKBKCE
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.
8Prof. Loganathan R, CSE,HKBKCE
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.
9Prof. Loganathan R, CSE,HKBKCE
The requirements elicitation & analysis Process
RequirementsClassification &
Organization
RequirementsPrioritization &
negotiation
10Prof. Loganathan R, CSE,HKBKCE
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
11Prof. Loganathan R, CSE,HKBKCE
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
12Prof. Loganathan R, CSE,HKBKCE
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.
13Prof. Loganathan R, CSE,HKBKCE
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.
14Prof. Loganathan R, CSE,HKBKCE
LIBSYS viewpoint hierarchy
InteractorIndirect
All VPs
Domain
15Prof. Loganathan R, CSE,HKBKCE
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.
16Prof. Loganathan R, CSE,HKBKCE
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.
17Prof. Loganathan R, CSE,HKBKCE
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’.
18Prof. Loganathan R, CSE,HKBKCE
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.
19Prof. Loganathan R, CSE,HKBKCE
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.
20Prof. Loganathan R, CSE,HKBKCE
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.
21Prof. Loganathan R, CSE,HKBKCE
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.
22Prof. Loganathan R, CSE,HKBKCE
Simple Use-case for Article printing• Actors is stick figures, each class of interaction is
named ellipse.
23Prof. Loganathan R, CSE,HKBKCE
Article printing
Use cases for library system
Article printing
Article search
Library
24Prof. Loganathan R, CSE,HKBKCE
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
25Prof. Loganathan R, CSE,HKBKCE
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.
26Prof. Loganathan R, CSE,HKBKCE
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.
27Prof. Loganathan R, CSE,HKBKCE
Ethnography and prototyping
DebriefingMeetings
EthnographicAnalysis
FocusedEthnography
28Prof. Loganathan R, CSE,HKBKCE
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.
29Prof. Loganathan R, CSE,HKBKCE
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.
30Prof. Loganathan R, CSE,HKBKCE
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?
31Prof. Loganathan R, CSE,HKBKCE
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
32Prof. Loganathan R, CSE,HKBKCE
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.
33Prof. Loganathan R, CSE,HKBKCE
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?
34Prof. Loganathan R, CSE,HKBKCE
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.
35Prof. Loganathan R, CSE,HKBKCE
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.
36Prof. Loganathan R, CSE,HKBKCE
Requirements evolution
ChangedUnderstanding of
Problem
InitialUnderstanding of
Problem
37Prof. Loganathan R, CSE,HKBKCE
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
38Prof. Loganathan R, CSE,HKBKCE
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
39Prof. Loganathan R, CSE,HKBKCE
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;
40Prof. Loganathan R, CSE,HKBKCE
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;
41Prof. Loganathan R, CSE,HKBKCE
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
42Prof. Loganathan R, CSE,HKBKCE
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.
43Prof. Loganathan R, CSE,HKBKCE
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.
44Prof. Loganathan R, CSE,HKBKCE
Change management
Problem Analysisand ChangeSpecification
ChangeImplementation
ChangeAnalysis and
costing
IdentifiedProblem
RevisedRequirements
45Prof. Loganathan R, CSE,HKBKCE
Specification costing