A reference to a set of Viewpoints: Viewpoints that receive the assistant services. service. Responsibilities: Responsibilities of the Constraints: Constraints on providing the viewpoint. service. Assumptions: Assumptions made about Implementation: How the service is the viewpoint. implemented. Relationships: Relationships to other Status: Current status of the service viewpoints. (proposed, approved etc). Priorities: Viewpoint priorities. Issues: Viewpoint issues. Rationale: Reason for the viewpoint.

1. Requirements Engineering Processes

2. Objectives
• To describe the principal requirements
engineering activities
• To introduce techniques for requirements
elicitation and analysis

3. Topics covered
• Feasibility studies
• Requirements elicitation and analysis
• Requirements validation
• Requirements management

4. Requirements engineering processes
• The processes used for RE vary widely
depending on the application domain, the
people involved and the organisation
developing the requirements
• However, there are a number of generic
activities common to all processes
– Requirements elicitation
– Requirements analysis
– Requirements validation
– Requirements management

5. The requirements engineering process
Feasibility Requirements
study elicitation and
analysis
Requirements
specification
Feasibility Requirements
report validation
System
models
U and system
ser
requirements
Requirements
document

6. Feasibility studies
• A feasibility study decides whether or not the
proposed system is worthwhile
• A short focused study that checks
– If the system contributes to organisational
objectives
– If the system can be engineered using current
technology and within budget
– If the system can be integrated with other
systems that are used

7. Feasibility study implementation
• Based on information assessment (what is required),
information collection and report writing
• Questions for people in the organisation
– What if the system wasn’t implemented?
– 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?

8. Requirements Elicitation and analysis
• Sometimes called requirements elicitation or requirements
discovery.
• Involves technical staff working with customers to find out
about the application domain, the services that the system
should provide and the system’s operational constraints.
• May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These are
called stakeholders.

9. Requirements Elicitation Techniques
• Interviewing and questionnaires.
• Brainstorming and idea reduction.
• Storyboarding.
• Role Playing.
• Requirements workshops.
• Prototyping.
• User Stories.
• Viewpoint-oriented elicitation
9

10. Technique: Interviewing
• Simple direct technique
• Context-free questions about what system
needs to do for the users
• Convergence on some common needs will
initiate a “requirements repository”
• A questionnaire is no substitute for an
interview, but may precede or follow
interviews
10

11. Interview:
Context-free questions
• Goal is to prevent prejudicing the user’s response to
the questions
• Examples:
– Who is the customer?
– Who is the user?
– Who is the user’s customer?
– Are their needs different?
– Where else can a solution to this problem be found?
• After context-free questions are asked, suggested
solutions can be explored
11

12. Technique: Brainstorming
• Brainstorming involves both idea generation and
idea reduction
• The most creative, innovative ideas often result from
combining seemingly unrelated ideas
• Various voting techniques may be used to prioritize
the ideas created
• Although live brainstorming is preferred, web-based
brainstorming may be a viable alternative
12

13. Rules for Brainstorming
• Do not allow criticism or debate
• Let your imagination soar
• Generate as many ideas as possible
• Mutate and combine ideas
• Only then do Idea Reduction
– Prune ideas that are not worthy of further discussion
– Group similar ideas into one super topic
• Prioritize the remaining ideas
13

14. Technique: Storyboarding
• Scripted walkthrough of system activities and/
or screen mockups
• Identify the players, explain what happens to
them, and describes how it happens
• Make the storyboard sketchy and easy to
modify
14

15. Technique: Role Playing
• Role playing allows developers to experience
the user’s world from the user’s perspective
• Live storyboard or unscripted walkthrough
• Generate system activities and/or screen
mockups as you go along
15

16. Technique:
Requirements Workshop
• Perhaps the most powerful technique for
eliciting requirements
• Gather all key stakeholders together for a
short but intensely focused period
• Use an outside facilitator experienced in
requirements management
• May combine interviewing, brainstorming,
storyboards, role playing
16

17. Technique: Prototyping
• Partial implementation of a software system,
built to help developers, users and customers
better understand system requirements
• Focus on the “fuzzy” requirements: poorly
defined and/or poorly understood
17

18. User Stories
• Written by the customers (or end-users) as
things that the system needs to do for them
• About 3 sentences in the customer’s
terminology, without technical detail
• Written on index cards (!)
• May be augmented by samples (e.g.,
formatted report)
• Prioritize (high, medium, low)
18

19. Example Story Card
111 Ins truc tor View
T inst uct v foragiv cour incl t
he r or iew en se udes he
cour number na a semest ; abuton t edit
se , me nd er t o
t int oduct abuton t designae l ayr v
he r ion; t o t ibr r eser es;
a abuton t a ustsetings fort cour
nd t o dj t he se.
Ot w t instuct v is t sa a
her ise he r or iew he me s
t st v .
he udent iew
Priority High
19

20. Continuing Example
222 S tudent View
T st v foragiv cour incl t
he udent iew en se udes he
cour number na a semest ; gener lcour
se , me nd er a se
infor t a inst uct infor t
maion; nd r or maion.
T e ae butons t sel intoduct discussion,
her r t o ect r ion,
boad, cl ss e- il dict r not d a hel
r a ma , ionay, epa nd p.
Priority High
20

21. Continuing Example
123 Ins truc tor vs . S tudent View
W a instuct sel s one oft cour
hen n r or ect he ses
he/ is t ching, t instuct v is show
she ea he r or iew n.
T instuct v shoul incl abuton t
he r or iew d ude t o
showt st v , a t t tspecia st
he udent iew nd hen ha l udent
v shoul incl abuton t sw ch ba t t
iew d ude t o it ck o he
inst uct v
r or iew
Priority Medium
21

22. Continuing Example
321 Login
T useris pr ed t ent uni a pa or
he ompt o er nd ssw d
Ift uni a pa or mach daa se,
he nd ssw d t t ba
t useris show t defa tscr w h his/
he n he ul een it her
l ofcurentcour
ist r ses
Priority High
22

23. Viewpoint-oriented elicitation
• Stakeholders represent different ways of
looking at a problem or problem viewpoints.
• This multi-perspective analysis is important as
there is no single correct way to analyse
system requirements

24. Banking ATM system
• The example used here is an auto-teller system which
provides some automated banking services.
• I use a very simplified system which offers some services
to customers of the bank who own the system and a
narrower range of services to other customers.
• Services include cash withdrawal, message passing (send a
message to request a service), ordering a statement and
transferring funds.

25. Autoteller viewpoints
• Bank customers
• Representatives of other banks
• Hardware and software maintenance engineers
• Marketing department
• Bank managers and counter staff
• Database administrators and security staff
• Communications engineers
• Personnel department

26. The VORD method
Viewpoint Viewpoint Viewpoint Viewpoint
identification structuring documentation system mapping

27. VORD process model
• Viewpoint identification
– Discover viewpoints which receive system services and identify the
services provided to each viewpoint
• Viewpoint structuring
– Group related viewpoints into a hierarchy. Common services are
provided at higher-levels in the hierarchy
• Viewpoint documentation
– Refine the description of the identified viewpoints and services
• Viewpoint-system mapping
– Transform the analysis to an object-oriented design

28. VORD Standard Forms
Viewpoint template Service template
Reference: The viewpoint name. Reference: The service name.
Attributes: Attributes providing Rationale: Reason why the service is
viewpoint information. provided.
Events: A reference to a set of event Specification: Reference to a list of service
scenarios describing how specifications. These may
the system reacts to be expressed in different
viewpoint events. notations.
Services A reference to a set of Viewpoints: List of viewpoint names
service descriptions. receiving the service.
Sub-VPs: The names of sub- Non-functional Reference to a set of non -
viewpoints. requirements: functional requirements
which constrain the service.
Provider: Reference to a list of system
objects which provide the
service.

29. Viewpoint identification
Query Get Customer Cash Transaction
balance transactions database withdrawal log
Manager Card Remote
Machine Order
returning software
supplies cheques
upgrade
Account Message Software
information log size Bank Invalid
User teller user
interface System cost Foreign
customer Printe
r Security
Account Stolen Order Hardware
card statement Card
holder maintenance retention
Message
passing
Remote Update Funds Card
Reliability account transfer
diagnostics validation

30. Viewpoint service information
ACCOUNT FOREIGN BANK
HOLDER CUSTOMER TELLER
Service list Service list Service list
Withdraw cash Withdraw cash Run diagnostics
Query balance Query balance Add cash
Or der cheques Add paper
Send message Send message
Transaction list
Or der statement
Transfer funds

31. Viewpoint data/control
ACCOUNT
HOLDER Control input Da ta input
Start transaction Card details
Cancel transaction PIN
End transaction Am ount required
Select service Message

32. Viewpoint hierarchy
All VPs
Services
Query balance
Withdraw cash Customer Bank staff
Services Account Foreign
Teller Manager Engineer
holder customer
Order cheques
Send message
Transaction list
Order statement
Transfer funds

33. Customer/cash withdrawal templates
Reference: Customer Reference: Cash withdrawal
Attributes: Account number Rationale: To improve customer service
PIN and reduce paperwork
Start transaction
Events: Select service Specification: Users choose this service by
Cancel pressing the cash withdrawal
transaction button. They then enter the
End transaction amount required. This is
confirmed and, if funds allow,
Services: Cash withdrawal the balance is delivered.
Balance enquiry
VPs: Customer
Sub-VPs: Account holder
Foreign Non-funct. Deliver cash within 1 minute
customer requirements: of amount being confirmed
Provider: Filled in later

34. Scenarios
• Scenarios are descriptions of how a system is
used in practice
• They are helpful in requirements elicitation as
people can relate to these more readily than
abstract statement of what they require from
a system
• Scenarios are particularly useful for adding
detail to an outline requirements description

35. Scenario descriptions
• System state at the beginning of the scenario
• Normal flow of events in the scenario
• What can go wrong and how this is handled
• Other concurrent activities
• System state on completion of the scenario

36. Event scenarios
• Event scenarios may be used to describe how a system
responds to the occurrence of some particular event such as
‘start transaction’
• VORD includes a diagrammatic convention for event
scenarios.
– Data provided and delivered
– Control information
– Exception processing
– The next expected event

37. Event scenario - start transaction
Card present
Valid card
Card User OK
Request PIN
PIN
Account Validate user Account
number number Select
PIN service
Timeout
Return card Incorrect PIN
Re-enter PIN
Invalid card
Return card
Incorrect PIN
Stolen card Return card
Retain card

38. Notation for data and control analysis
• Ellipses. data provided from or delivered to a
viewpoint.
• Control information enters and leaves at the
top of each box.
• Data leaves from the right of each box.
• Exceptions are shown at the bottom of each
box.
• Name of next event is in box with thick edges

39. Exception description
• Most methods do not include facilities for
describing exceptions
• In this example, exceptions are
– Timeout. Customer fails to enter a PIN within the
allowed time limit
– Invalid card. The card is not recognised and is
returned
– Stolen card. The card has been registered as
stolen and is retained by the machine

40. The requirements analysis process
Requirements
definition and
Requirem ents specification
validati
on
Domain
Prioritization
understanding
Process
entry
Requirements Conflict
collection resolution
Classification

41. System models
• Different models may be produced during the requirements
analysis activity.
• Requirements analysis may involve three structuring activities
which result in these different models.
– Partitioning. Identifies the structural (part-of) relationships between
entities.
– Abstraction. Identifies generalities among entities.
– Projection. Identifies different ways of looking at a problem.

42. Requirements Verification
• Concerned with demonstrating that 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

43. Requirements checking
• Validity. Does the system provide the functions which best
support the customer’s 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

44. Requirements management
• Requirements management is the process of managing
changing requirements during the requirements engineering
process and system development
• Requirements are inevitably incomplete and inconsistent
– 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

45. Problems of requirements analysis
• Stakeholders don’t know what they really want
• Stakeholders express requirements in their own terms
• Different stakeholders may have conflicting requirements
• Organisational and political factors may influence the system
requirements
• The requirements change during the analysis process. New
stakeholders may emerge and the business environment
change

46. Key points
• The requirements engineering process
includes a feasibility study, requirements
elicitation and analysis, requirements
specification and requirements management
• Requirements analysis is iterative involving
domain understanding, requirements
collection, classification, structuring,
prioritisation and validation
• Systems have multiple stakeholders with
different requirements

47. Key points
• Social and organisation factors influence
system requirements
• Requirements validation is concerned with
checks for validity, consistency, completeness,
realism and verifiability
• Business changes inevitably lead to changing
requirements
• Requirements management includes planning
and change management