Post on 05-Apr-2018
8/2/2019 Ch 7 Requirements Engineering Processes
1/54
1
Chapter 7
Requirements Engineering Processes
Haya Sammaneh
8/2/2019 Ch 7 Requirements Engineering Processes
2/54
8/2/2019 Ch 7 Requirements Engineering Processes
3/54
3
Topics covered
Feasibility studies
Requirements elicitation and analysis
Requirements validationRequirements management
8/2/2019 Ch 7 Requirements Engineering Processes
4/54
4
Requirements Engineering processes
The processes used for RE vary widely depending
on the application domain, the people involvedand the organization developing the requirements
However, there are a number ofgeneric activitiescommon to all processes
Feasibility study
Requirements elicitation and analysis
requirements specification and systemmodeling.
Requirements validation
Requirements management
8/2/2019 Ch 7 Requirements Engineering Processes
5/54
5
The requirements engineering process
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and system
requirements
Requirements
document
8/2/2019 Ch 7 Requirements Engineering Processes
6/54
6
The Spiral model of requirementsengineering Process
Requirements
specification
Requirements
validation
Requirementselicitation
System requirements
specification andmodeling
System
requirementselicitation
User requirementsspecification
Userrequirements
elicitation
Business requirementsspecification
Prototyping
Feasibility
study
Reviews
System requirementsdocument
8/2/2019 Ch 7 Requirements Engineering Processes
7/54
7
7.1Feasibility studies
A feasibility study decides whether or not the proposedsystem is worthwhile
A short focused study that checks If the system contributes to organizational objectives
If the system can be engineered using current technology
and within budget
If the system can be integrated with other systems thatare used
8/2/2019 Ch 7 Requirements Engineering Processes
8/54
8
Feasibility study implementation
Based on information assessment , informationcollection and report writing
Questions for people in the organization
What if the system wasnt implemented?
What are current process problems?
How will the proposed system help?
What will be the integration problems? Is new technology needed?
What facilities must be supported by the proposedsystem?
8/2/2019 Ch 7 Requirements Engineering Processes
9/54
9
7.2Requirements Elicitation (discovery)
and analysis
Involvestechnical staff working with customers,the services that the system should provide and
the systems operational constraints
May involveend-users, managers, engineers
These are called stakeholders
8/2/2019 Ch 7 Requirements Engineering Processes
10/54
10
Problems of requirements analysis
Stakeholders dont know what they really want
Stakeholders express requirements in theirown terms
Different stakeholders may have conflicting requirements
Organizational and politicalfactors may influence the
system requirements
The requirements change during the analysis process. Newstakeholders may emerge and the business environment
change
8/2/2019 Ch 7 Requirements Engineering Processes
11/54
11
The requirements analysis process
Requirementsvalidation
Domain
understandingPrioritization
Requirementscollection
Conflictresolution
Classification
Requirementsdefinition andspecification
Processentry
8/2/2019 Ch 7 Requirements Engineering Processes
12/54
12
The requirements Analysis Spiral
Requirementsclassification and
organisation
Requirementsprioritization and
negotiation
RequirementsdocumentationRequirementsdiscovery
8/2/2019 Ch 7 Requirements Engineering Processes
13/54
13
requirements analysis Process(activities
Requirements collection, interact with stakeholders, domainrequirements (understanding.
Classification and organization, organize requirement in a
structure one (coherent cluster.
Conflict resolution, resolving the conflict.
Prioritization, prioritize requirements.
Requirements checking and documentation, checking forcompletion, consistency, and in accordance with whatstakeholder really wants, then documented for the next
phase.
8/2/2019 Ch 7 Requirements Engineering Processes
14/54
14
7.2.1Requirements discovery(Viewpoints, interview , scenario, use case
The process ofgathering informationabout the proposed and existing systemsand eliciting the user and system
requirements from this information.
Sources of information include
documentation, system stakeholders andthe specifications of similar systems.
8/2/2019 Ch 7 Requirements Engineering Processes
15/54
15
a. Viewpoint-oriented approach
Stakeholdersrepresent different ways oflooking at a problem
Viewpoints are a way ofstructuring therequirements to represent the perspectives ofdifferent stakeholders..
This multi-perspective analysisis important asthere is no single correct way to analyzesystem requirements.
8/2/2019 Ch 7 Requirements Engineering Processes
16/54
16
Example - Banking (auto-teller system ATMsystem
The example used here is an auto-teller systemwhich provides some automated banking services
we use a very simplified system which offers someservices to customers of the bank who own thesystem and a narrowerrange of services to othercustomers
Services include cash withdrawal, messagepassing (send a message to request a service,ordering a statement and transferring funds
8/2/2019 Ch 7 Requirements Engineering Processes
17/54
17
Auto-tellerviewpoints
Bank customers
Representatives of other banks: allow otherATM to be used
Hardware and software maintenance engineers Marketing department
Bank managers and staff
Database administrators and security staff
Communications engineers Personnel department
Stakeholder+ domain + system can be represented as systemviewpoints
8/2/2019 Ch 7 Requirements Engineering Processes
18/54
18
Types (Models of viewpoint Interactor viewpoints
People orother systems that interact directly with thesystem.
In an ATM, the customers and the account databaseare interactor VPs.
Indirect viewpoints
Stakeholders who do not use the system themselvesbut who influence the requirements.
In an ATM, managementand security staff are indirectviewpoints.
Domain viewpoints
Domain characteristics and constraints that influencethe requirements.
In an ATM, the standards for inter-bankcommunications.
8/2/2019 Ch 7 Requirements Engineering Processes
19/54
19
LIBSYS viewpoint hierarchy
Article
providersFinance
Library
m anager
Library
staffU sers
InteractorIndirect
All VPs
Classificationsystem
UI
standards
Dom ain
ExternalStaffStudents CataloguersSystem
m anagers
8/2/2019 Ch 7 Requirements Engineering Processes
20/54
20
Viewpoint process model
Viewpoint identification: discover viewpoints whichreceive system services and identify the servicesprovided to each viewpoint using:
Providers and receivers of system services; Systems that interact directly with the system being specified; Regulations and standards; Engineers who have to develop and maintain the system; Marketing and otherbusiness viewpoints.
8/2/2019 Ch 7 Requirements Engineering Processes
21/54
21
Viewpoint process model, cont
Viewpoint structuring, group related viewpointsinto a hierarchy. Common services are providedat higher-levels in the hierarchy
Viewpoint documentation, refine the descriptionof the identified viewpoints and services
Viewpoint-system mapping, transform theanalysis to an object-oriented design
8/2/2019 Ch 7 Requirements Engineering Processes
22/54
22
Viewpoint identification
Querybalance
Gettransactions
Cashwithdrawal
Transactionlog
Machinesupplies
Cardreturning
Remotesoftwareupgrade
Ordercheques
Userinterface
Accountinformation
Messagelog
Softwaresize Invalid
userSystem cost Printe
r Security
Cardretention
Stolen
card
Order
statement
Remotediagnostics
ReliabilityUpdateaccount
Fundstransfer
Messagepassing
Cardvalidation
Customerdatabase
Manager
Accountholder
Foreigncustomer
Hardwaremaintenance
Bankteller
8/2/2019 Ch 7 Requirements Engineering Processes
23/54
23
b. Interviewing
In formal orinformal interviewing, the REteam puts questions to stakeholdersabout the system.
There are two types of interview Closed interviews where a pre-defined set of
questions are answered.
Open interviews where there is no pre-definedagenda and a range of issues are exploredwith stakeholders.
8/2/2019 Ch 7 Requirements Engineering Processes
24/54
24
Interviews in practice
Normally a mix of closed and open-endedinterviewing.
Interviews are good for getting an overallunderstanding ofwhat stakeholders do and howthey interact with the system.
8/2/2019 Ch 7 Requirements Engineering Processes
25/54
25
Effective interviewers
Interviewers should be open-minded, willing to
listen to stakeholders and should not have pre-
ideas about the requirements.
They should prompt the interviewee with a
question or a proposal and should not simply
expect them to respond to a question such aswhat do you want.
8/2/2019 Ch 7 Requirements Engineering Processes
26/54
26
c. Scenarios
Scenarios are descriptions ofhow a system isused in practice, a real-life examples of how asystem can be used.
Scenarios are particularly useful for adding detailto an outline requirements description
8/2/2019 Ch 7 Requirements Engineering Processes
27/54
27
Scenario include:
description of the system state at thebeginning of the scenario
Normal flow of events in the scenario
What can go wrong and how this is handled
Otherconcurrent activities
description of the System state on completionof the scenario
8/2/2019 Ch 7 Requirements Engineering Processes
28/54
28
Event scenarios
Event scenarios may be used to describe how a systemresponds to the occurrence of some particular eventsuch as start transaction
8/2/2019 Ch 7 Requirements Engineering Processes
29/54
29
Event scenarios, cont
The diagrammatic notations used in eventscenarios are: Data provided and delivered from/to a
viewpoint is shown in ellipses. Control information, enter and leave at the
top of each box. Exception processing, shown at the
bottom of the box. Name of the next expected event is shown
in a shaded box
8/2/2019 Ch 7 Requirements Engineering Processes
30/54
30
Event scenario - start transaction
Validate user
Request PIN
Selectservice
Timeout
Return card
Invalid card
Return card
Stolen card
Retain card
Incorrect PIN
Re-enter PIN
Incorrect PIN
Return card
Card
PIN
Card present
Account
numberPIN
Account
number
Valid card
User OK
8/2/2019 Ch 7 Requirements Engineering Processes
31/54
31
Exception description
In the previous example, exceptions are: Timeout, customer fails to enter a PIN within the
allowed time limit Invalid card, the card is not recognized and is
returned Stolen card, the card has been registered as
stolen and is retained by the machine
8/2/2019 Ch 7 Requirements Engineering Processes
32/54
32
c. Use cases Use-cases are a scenario based technique for
requirement elicitation in the UML notations thatused in object-oriented system model (UnifiedModelling Language which identify the actors in
an interaction and which describe the interactionitself
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 event in
the system
8/2/2019 Ch 7 Requirements Engineering Processes
33/54
33
Use cases, cont..
The sequence diagram (ch 6) is used to add
information to use-case.
The sequence diagram shows the:
1- actors used in the interaction
2- objects that the actors interact with.3- operation associated with these objects.
8/2/2019 Ch 7 Requirements Engineering Processes
34/54
34
Library system , example.
Interaction fordownloading and printing
article.
Objects used in this interaction are:
1. Article
2. Form
3. workspace4. printer
8/2/2019 Ch 7 Requirements Engineering Processes
35/54
35
Lending use-case
Lending services
8/2/2019 Ch 7 Requirements Engineering Processes
36/54
36
use-cases for Library system
Lending services
User administration
Supplier Catalog services
Library
User
Library
Staff
8/2/2019 Ch 7 Requirements Engineering Processes
37/54
37
Example ofsequence diagram of Printing article.
User
item:Article
copyrightForm:Form
request
complete
myWorkspace:Workspace
myPrinter:Printer
request
return
copyright OK
deliver
article OK
printsend
confirminform
delete
8/2/2019 Ch 7 Requirements Engineering Processes
38/54
38
7.3Requirements validation
Concerned with demonstrating that the requirements definethe system that the customer really wants
Requirements error costs are high so validation is veryimportant
Fixing a requirements errorafter deliverymay cost up to100 times the cost of fixing an implementation error
Change requirement error means change system designand implementation
8/2/2019 Ch 7 Requirements Engineering Processes
39/54
39
Requirements checking(types of checksshould be carried out on requirements)
Validity. Does the system provide the functions which bestsupport the customers needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer
included? Realism. Can the requirements be implemented given
available budget and technology
Verifiability. Can the requirements be checked? In order to
reduce potential dispute between customers.Should be write a set of test that can be demonstrate thatthe delivered system meet each specified requirements.
8/2/2019 Ch 7 Requirements Engineering Processes
40/54
40
Requirements validationtechniques
Requirements reviews, systematic manual analysis of therequirements
Prototyping, using an executable model of the system to
check requirements.
Test-case generation, developing tests for requirements tocheck testability of requirement.
Automated consistency analysis , checking theconsistency of a structured requirements description, if therequirements are expressed in structured or formal notation,
then CASE tool may be used to check the consistency.
8/2/2019 Ch 7 Requirements Engineering Processes
41/54
41
6.3.1Requirementsreviews
Regular reviews should be held while the requirementsdefinition is being formulated
Both client and contractorstaff should be involved inreviews
Reviews may be formal (with completed documents or
informal.
Good communications between developers, customers canresolve problems at an early stage
8/2/2019 Ch 7 Requirements Engineering Processes
42/54
42
Review checks:
Verifiability. Is the requirement realisticallytestable?
Comprehensibility. Is the requirement properlyunderstood?
Trace-ability. Is the source of the requirementclearly stated?
Adaptability. Can the requirement be changed
without a large impact on other requirements?
8/2/2019 Ch 7 Requirements Engineering Processes
43/54
43
7.4Requirements management
Requirements management is the process of managingchanging requirementsduring the requirementsengineering process andsystem development
Requirements are inevitably incomplete and inconsistentbecause:
New requirements emerge during the process becausebusiness needs change and a better understanding of
the system is developed
Different viewpoints have different requirements andthese are often contradictory
8/2/2019 Ch 7 Requirements Engineering Processes
44/54
44
Requirements change because of:
Thepriority of requirements from different viewpointschanges during the development process
System customers may specify requirements from abusiness perspective that conflict with end-userrequirements.
(customers-people who pay for the system- and end-user-people who use the system- usually different
The business and technical environment of the systemchanges during its development
8/2/2019 Ch 7 Requirements Engineering Processes
45/54
45
7.4.1Enduring and volatile requirements
Enduring requirements.Stable requirements derived fromthe core activity of the customer organization. E.g. ahospital will always have doctors, nurses, etc.
Volatile requirements. Requirements which changeduringdevelopment or when the system is in use. In a hospital,requirements derived from health-care policy
8/2/2019 Ch 7 Requirements Engineering Processes
46/54
Classification of Volatile requirements
Mutable requirements, requirements thatchange due to the changing ofsystemsenvironment
Emergent requirements, requirements thatemerge as understanding of the systemdevelops during the system development.
8/2/2019 Ch 7 Requirements Engineering Processes
47/54
47
Classification of Volatile requirements
Consequential requirements,requirements that result from theintroduction of the computersystem that
result to new process which may generatenew requirements.
Compatibility requirements, requirements
that depend on other systems
8/2/2019 Ch 7 Requirements Engineering Processes
48/54
48
7.4.2Requirements management planning
During the requirements engineering process, you haveto plan on:
Requirements identification, howrequirements are individually identified
A change management process, the processfollowed when analyzing a requirementschange (the impact and cost of change
8/2/2019 Ch 7 Requirements Engineering Processes
49/54
49
Requirements management planning,cont..
Traceability policies, the amount ofinformation about requirements relationshipsare recorded and how it should be maintained
CASE toolsupport which required to helpmanage requirements change, using
spreadsheets and databases.
8/2/2019 Ch 7 Requirements Engineering Processes
50/54
Traceability Traceability is concerned with the relationships between
requirements, their sources andrelationships betweenrequirements and the system design
There are three types of traceability:
Source traceability, links from requirements tostakeholders who proposed these requirements
Requirements traceability, links between dependentrequirements
Design traceability, links from the requirements to thedesign,
A traceability matrix
8/2/2019 Ch 7 Requirements Engineering Processes
51/54
51
A traceability matrixR- weak relationship
U- row use facility of column, shows dependency between reqs
Req. in the row depends on the Req. in the column
7 4 3Requirements change management
8/2/2019 Ch 7 Requirements Engineering Processes
52/54
52
7.4.3Requirements change managementprocess
Should be applied to all proposedchanges to therequirements. The advantage of using a formal process forchange management is that all change proposals are treatedconsistently.
Principal stages to a change management process:
Problem analysis. Discuss requirements problem andpropose change
Change analysis and costing. Assess effects of changeon other requirements
Change implementation. Modify requirements documentand other documents to reflect change
8/2/2019 Ch 7 Requirements Engineering Processes
53/54
53
Key points
The requirements engineering process includes a feasibilitystudy, requirements elicitation and analysis, requirementsspecification and requirements management
Requirements analysis is iterative involving domainunderstanding, requirements collection, classification,structuring, prioritization and validation
Systems have multiple stakeholders with differentrequirements
8/2/2019 Ch 7 Requirements Engineering Processes
54/54
54
Key points
Social and organisation factors influence systemrequirements
Requirements validation is concerned with checks forvalidity, consistency, completeness, realism andverifiability
Business changes inevitably lead to changingrequirements
Requirements management includes planning and