Transcript Requirements Elicitation Requirements Engineering (IF 51XX)

Requirements Analysis
Requirements Engineering (CI 2323)
Daniel Siahaan
Content
•
•
•
•
•
•
•
•
Introduction to Requirements Engineering
Add-on: Scenario
Feasibility Studies
Requirements Elicitation
Creativity Thinking
Requirements Analysis
Requirements Specification
Requirements Validation
Requirements 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 stakeholders: end-users, managers,
engineers involved in maintenance, domain
experts, trade unions, etc.
Requirements Analysis
• Acquire understanding about the problem domain characteristics
and problem to find the solution
• It is an information-acquiring, -collating, and –structuring process
through which one attempts to understand all the various parts of a
problem and their relationships.
• Basic Issues:
– How to effectively elicit a complete set of requirements from
the customer or other sources?
– How to decompose the problem into intellectually manageable
pieces?
– How to organize the information so it can be understood?
– How to communicate about the problem with all the parties
involved?
– How to resolve conflicting needs?
– Ho to know when to stop?
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
• Using modeling techniques, e.g. UML
The requirements analysis process
Requir ements
definition and
specification
Requirements
validation
Process
entry
Domain
understanding
Prioritization
Requirements
collection
Conflict
resolution
Classification
Methods for Requirements Analysis
•
•
•
•
Structured Analysis
Object Oriented Analysis
Problem Domain Oriented Analysis
Viewpoint Oriented Analysis
Structured Analysis
• Centered upon modeling the pre-existing system
– Process
– Data flow
– Structure of data stored
• Weakness:
– Downplay the study of the problem domain
– Requirements are specified in term of idesign
– Lack of sharp boundary between analysis and design
encourage premature idesign
– Functional specification is absent
– Ill-suited for certain (not rarely) types of application
Object Oriented Analysis
• It’s not really an analysis:
– It requires pre-existing requirements document and
behaviour specification.
• High-level, architectural, design of the solution
system.
• OOA Outline:
–
–
–
–
Identify object classes within the problem domain
Define the attribute and methods of those classes
Define the behaviour of those classses
Model the relationships between those classes
Object Oriented Analysis
• Three perspective of class model
– Specification (i.e. interface classes)
– Conceptual (i.e. problem domain classes – related to
analysis)
– Implementation (i.e. related to internal design)
Problem Domain Oriented Analysis
• Centered on modeling the problem context
– Problem frames: capture significantly more
information about the problem domain
• Less modeling, more description, procedure:
– Collect basic information and develop problem
frame(s) to establish the type of the problem domain
– Collect further detail and develop description of the
relevant characteristics of the problem domain
– Collect and document the requirements for the new
system
Problem Domain Oriented Analysis
• Type of problem domain:
– Workpiece system – perform directed operations upon
objects that exist only within the system
– Control system – control the behavior (requiredcommanded) of part of the problem domain
– Information system – provide information (automaticallyresponsively) about the problem domain
– Transformation system – transform input data in a particular
format into output data in a corresponding, particular format
– Connection system – maintain correspondence between subdomains that are not directly connected
Viewpoint-oriented analysis
• Stakeholders represent different ways of
looking at a problem or problem viewpoints
– different types of stakeholders
– different views among stakeholders of same type
• This multi-perspective analysis is important as
there is no single correct way to analyse system
requirements
Multiple problem viewpoints
Problem
to be
analysed
Autoteller 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
Extra Assignments
• Study Literature: VORD
– Contents (5-6 pages, 11p, 1.5space):
• Overview (What, Why, and How)
• Advantage – Disadvantage
• Practical Approach
– Sources:
• G. Kotonya and I. Sommerville, "Requirements Engineering with
Viewpoints", Software Eng. Journal 1996; 11(1): 5-11
• I Sommerville and P Sawyer, “Viewpoints: Principles, Problems, and a
Practical Approach to RE”, Cooperative System Engineering Group,
Technical Report. 1997.
• Finkelstein et.al., “Requirements Engineering Through Viewpoints”,
Departement of Computing, Imperial College, 2000.
– Due Date: April 29th, 2005
– Discussion Date: May 17th, 2005
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
Types of viewpoint
• Data sources or sinks
– Viewpoints are responsible for producing or consuming data.
Analysis involves checking that data is produced and
consumed and that assumptions about the source and sink of
data are valid
• Representation frameworks
– Viewpoints represent particular types of system models.
These may be compared to discover requirements that would
be missed using a single representation. Particularly suitable
for real-time systems
• Receivers of services
– Viewpoints are external to the system and receive services
from it. Most suited to interactive systems
External viewpoints
• Natural to think of end-users as receivers of
system services
• Viewpoints are a natural way to structure
requirements elicitation
• It is relatively easy to decide if a viewpoint is
valid
• Viewpoints and services may be sued to
structure non-functional requirements
The VORD method
Viewpoint
identification
Viewpoint
structuring
Viewpoint
documenta tion
Viewpoint
system ma pping
VORD standard forms
Vie wpoint te mplate
Re fer ence :
The viewpoint na me .
Attr ibutes:
Attribute s
providing
viewpoint informa tion.
Events:
A re fere nc e to a se t of
e ve nt
sc enarios de scribing how
the system rea cts to
viewpoint events.
Ser vic es
A re fere nc e to a se t of
se rvic e desc riptions.
Sub-VPs:
The nam es of
subviewpoints.
Ser vic e te mplate
Re fer ence :
The se rvic e nam e.
Rationale :
Re ason why the se rvic e is
provide d.
Spe cific ation:
Re fere nc e to alist of service
spec ifica tions. The se m ay
be e xpresse d in diffe rent
nota tions.
Vie wpoints:
List of vie wpoint nam es
re ce iving the se rvic e .
Non-func tional
Re fere nc e to a set of non r equir ements:
func tional
re quirem ents
which constra in the service .
Pr ovide r:
Re fere nc e to alist of syste m
obje cts which provide the
se rvic e.
Viewpoint identification
Query
balance
Machine
supplies
Get
transactions
Customer
database
Account
holder
Remote
diagnostics
Card
returning
Manager
Message
log
Account
information
User
interface
System cost
Stolen
card
Reliability
Cash
withdrawal
Foreign
customer
Order
statement
Update
account
Software
size
Printe
r
Hardware
maintenance
Funds
transfer
Transaction
log
Remote
software
upgrade
Order
cheques
Bank
teller
Invalid
user
Security
Message
passing
Card
retention
Card
validation
Viewpoint service information
ACCOUNT
HOLDER
Service list
Withdraw cash
Query balance
Or der cheques
Send message
Transaction list
Or der statement
Transfer funds
FOREIGN
CUSTOMER
Service list
Withdraw cash
Query balance
BANK
TELLER
Service list
Run diagnostics
Add cash
Add paper
Send message
Viewpoint hierarchy
All VPs
Services
Query balance
Withdraw cash
Services
Order cheques
Send message
Transaction list
Order statement
Transfer funds
Customer
Account
holder
Foreign
customer
Bank staff
Teller
Manager
Engineer
Customer/cash withdrawal templates
Reference: Customer
Reference:
Cash withdrawal
Attributes: Account number
PIN
Start transaction
Events:
Select service
Cancel
transaction
End transaction
Rationale:
To improve customer service
and reduce paperwork
Services:
Cash withdrawal
Balance enquiry
Specification: Users choose this service by
pressing the cash withdrawal
button. They then enter the
amount required. This is
confirmed and, if funds allow,
the balance is delivered.
VPs:
Sub-VPs:
Account holder
Foreign
customer
Customer
Deliver cash within 1 minute
Non-funct.
requirements: of amount being confirmed
Provider:
Filled in later
Method advantages/disadvantages
• Methods impose structure on the requirements
analysis process
• May be supported by CASE tools
• Can be applied systematically and can lead
naturally to design
• However, forces system modelling using a
computational framework
• Methods fail to adequately provide for the
description of human activities
System contexts
• The boundaries of the system must be
established to determine what must be
implemented
• These are documented using a description of the
system context. This should include a
description of the other systems which are in
the environment
• Social and organisational factors may
influence the positioning of the system
boundary
Auto-teller system context
Security
system
Branch
accounting
system
Account
database
Auto-teller
system
Branch
counter
system
Usage
database
Maintenance
system
Social and organisational factors
• Software systems are used in a social and
organisational context. This can influence or
even dominate the system requirements
• Social and organisational factors are not a
single viewpoint but are influences on all
viewpoints
• Good analysts must be sensitive to these factors
but currently no systematic way to tackle their
analysis
Ethnographic analysis
• A social scientists spends a considerable time
observing and analysing how people actually
work
• People do not have to explain or articulate their
work
• Social and organisational factors of importance
may be observed
• Ethnographic studies have shown that work is
usually richer and more complex than suggested
by simple system models
Key points
• Requirements analysis requires domain
understanding, requirements collection,
classification, structuring, prioritisation and
validation
• Complex systems should be analysed from
different viewpoints
• Viewpoints may be based on sources and sinks
of data, system models or external interaction
Key points
• Structured methods may be used for requirements
analysis. They should include a process model, system
modelling notations, rules and guidelines for system
modelling and standard reports
• The VORD viewpoint-oriented method relies on
viewpoints which are external to the system
• The boundaries between a system and its environment
must be defined
• Social and organisational factors have a strong
influence on system requirements