Requirement Engineering

Use Case Modeling
Chapter 7 of the Text Book

and
Applying Use Cases: A Practical Guide
Geri Schneider and Jason P. Winters
Object-Oriented Software Engineering
Practical Software Development using UML and Java
Requirement
Engineering
Chapter 4, 7, and some

additional Material
Recap
• Software development is a multi-
activity process. It is not simply
coding.
• Software construction and
management
• Software Engineering Framework
• Software engineering phases
• Importance of Maintenance
Software Construction
• What is the problem to be solved?
• What are the characteristics of the entity that
is used to solve the problem?
• How will the entity be realized?
• How will the entity be constructed?
• What approach will be used to uncover errors
that were made in the design and
construction of the entity?
• How will the entity be supported over the
long term, when corrections, adaptations, and
enhancements are requested by users of the
entity?
Software Engineering Phases
• Vision – focus on why

• Definition – focus on what
• Development – focus on
how
• Maintenance – focus on
change
Requirement Engineering
• The entire system development
process begins with requirement
engineering.
• The process of establishing the
system services and constraints is
called requirement engineering.
• What vs. How
Software Requirements –
Definition - IEEE
1 A condition or capability needed by
user to solve a problem or achieve an
objective.
2 A condition or capability that must be
met or possessed by a system or
system component to satisfy a
contract, standard, specification, or
other formally imposed document.
3 A documented representation of a
condition or capability as in 1 or 2.
Definition - Jones
• The statement of needs by a user that
triggers the development of a
program or system - Jones 1994
Definition – Davis
• A user need or necessary feature,
function, or attribute of a system that
can be sensed from a position
external to that system - Alan Davis
1993
Software Requirements -
Definition
• Requirements are ... A specification of
what should be implemented. They
are descriptions of how the system
should behave, or of a system
property or attribute. They may be a
constraint on the development
process of the system. - Sommerville
1997
Importance of the Software
Requirement Process
The hardest single part of building a
software system is deciding precisely
what to build. No other part of the
conceptual work is as difficult as
establishing the detailed technical
requirements, including all the
interfaces to people, to machines, and
to other software systems. No other part
of the work so cripples the system if
done wrong. No other part is more
difficult to rectify later.
Importance of
Requirements
• Many of the problems encountered in SW
development are attributed to shortcoming in
requirement gathering and documentation
process.
• Building a house without requirements: no –
building a software: yes
• 40-60% of all defects found in software
projects can be traced back to poor
requirements
• Interest of all stakeholders in a project is must
Importance of requirements
Cost of Requirement Creep
Requirement Origins and Comparative Costs
250
200
150
100
50
0
ng
t
g
lity
en
sig
in
di
m
st
bi
De
Co
Te
i
ire
as
qu
Fe
Re
Development Phases
Rate of Growth Comparartive Costs

Benefits of high quality
requirement process
• Boehm(1981) – correcting an error
after development costs 68 times
more
• Other studies suggest that it can be
as high as 200 times.
• Hence requirements are the most
critical success factor for any project
Role of Requirements
Project
Planning
Construction Project
Process Tracking
Software
Requirements
User Change
Documentation Control
System
Testing
Levels of Requirements
• Business Requirements
– Represent high level objectives of the
organization or customer requesting
the system or product
– Captured in a document describing
the project vision and scope.
• User Requirements
– Describes tasks the user must be able
to accomplish
4.5 Types of Requirements
• Functional requirements
– Describe what the system should do
– Define the software functionality the
developers must build into the product to
enable users to accomplish their tasks -
thereby satisfying the business
requirements.
• Non-functional requirements
– Constraints or restrictions that are placed
on the choices available to the developer for
design and construction of the software
product.
© Lethbridge/Laganière Chapter 4: Developing
18
2001 requirements
Functional requirements
– What inputs the system should accept
– What outputs the system should
produce
– What data the system should store that
other systems might use
– What computations the system should
perform
– The timing and synchronization of the
above

19
2001 requirements
Non-functional requirements
• All must be verifiable
• Three main types
1. Categories reflecting: usability, efficiency,
reliability, maintainability and reusability
• Response time
• Throughput
• Resource usage
• Reliability
• Availability
• Recovery from failure
• Allowances for maintainability and enhancement
• Allowances for reusability

20
2001 requirements
Non-functional
requirements
2. Categories constraining the environment and
technology of the system.
• Platform
• Technology to be used
3. Categories constraining the project plan and

development methods
• Development process (methodology) to be used
• Cost and delivery date
– Often put in contract or project plan instead

21
2001 requirements
• All user requirements must align with
business requirements
• Requirements do not include design
or implementation details.
• Focus on what to build.
Kinds of requirements
• BR – user will be able to correct spelling errors in
a document efficiently.
– Spell checker is included as a feature
• UR – finding spelling errors in the document and
decide whether to replace each misspelled word
with the one chosen from a list of suggested
words.
• FR
– find and highlight misspelled words.
– Display a dialog box with suggested replacements
– Making global replacements
• NFR – It must be integrated into the existing
word-processor which runs on windows platform.
Requirement Engineering
Issues
• Process Issues
– Stake holder identification and
involvement.
– Managing Requirement Creep.
• Requirement Quality Issues
– ambiguity
– completeness
– consistency
– Gold-plating
Stake Holders
• Stake holders – different people who would

be interested in the software.
• Management carries a lot of weight, but are
they the actual users?
• Acceptance of the software depends upon
whom?
• Stakeholders have very general and vague
requirements. Some times they trivialize
things.
• Different stake holders have different
requirements – sometimes even conflicting.
• Analysis takes place in an organizational
Stake Holders
M anagem ent M a r k e tin g
P r o v id e s B u s in e s s S p e c ifie s H ig h L e v e l
R e q u i r e m e n t s a n d P r o je c t R e q u ir e m e n ts
P a ra m e te rs
S o ftw a re
R e q u ire m e n ts
s p e c ifie s h a rd w a r e
a llo c a te s s y s te m
in te r fa c e s th e s o ftw a r e m u s t
re q u ir e m e n ts to s o ftw a r e
re s p e c t
d e s c r ib e u s e r
r e q u ir e m e n ts a n d q u a lity
a ttr ib u te s
S y s te m s H a rd w a re
E n g in e e r in g E n g in e e r in g
U s e rs
Stake holders - User classes
• A study of over 8300 projects revealed
that the top two reasons for any project
failure are lack of user input and
incomplete requirements.
• Example of menu driven system for
power users
– supposed to replace the existing system
but failed because of this reason.
Example of minimal
requirements
• We need a flow control and source
control engineering tool.
• Worked perfectly but
– There was no print functionality
Example of minimal
requirements
• The system should maintain the
hourly level of reservoir from depth
sensor situated in the reservoir. The
values should be stored for the past
six months.
• AVERAGE: Average command
displays the average water level for a
particular sensor between two times.
Ambiguous requirements
• Ambiguity – arising from natural
language
– Sommerville – no output is better
than wrong output.
– Rooko mut jane do
• Leads to different expectations
• Waste of time and effort
Ambiguous requirements
• Multiple readers arrive at different
understanding
– The operator identity consists of the
operator name and password; the
password consists of six digits. It
should be displayed on the security
VDU and deposited in the login file
when an operator logs into the
system
Ambiguous Requirements
• System should be user friendly
• System should have a good user
interface
• It should perform operations
efficiently
• It should respond to queries quickly
Contradiction
• All programs must be written in Ada
• The program must fit in the memory
of the embedded micro-controller
• Problem: Code generated by the Ada
compiler was of large foot print – it
would not fit.
Contradiction
• System must monitor all
temperatures in a chemical reactor.
• System should only monitor and log
temperatures below -200 C and
above 4000 C.
Some Risks From
Inadequate Requirement
Process
• Insufficient user involvement leads to unacceptable
products.
• Creeping user requirements contribute to overruns
and degrade product quality.
• Ambiguous requirements lead to ill-spent time and
rework.
• Minimal specifications lead to missing key
requirements.
• Overlooking the needs of certain user classes
(stake holders) leads to dissatisfied customers.
• Incompletely defined requirements make accurate
project planning and tracking impossible.
• Gold-plating by developers and users adds
User Centred Design
• Software development should focus on the
needs of users
– Understand your users
– Design software based on an understanding of
the users’ tasks
– Ensure users are involved in decision making
processes
– Design the user interface following guidelines
for good usability
– Have users work with and give their feedback
about prototypes, on-line help and draft user
manuals
The importance of focusing
on users
– Reduced training and support costs
– Reduced time to learn the system
– Greater efficiency of use
– Reduced costs by only developing features that
are needed
– Reduced costs associated with changing the
system later
– Better prioritizing of work for iterative
development
– Greater attractiveness of the system, so users
will be more willing to buy and use it
Characteristics of Users
• Software engineers must develop an
understanding of the users
– Goals for using the system
– Potential patterns of use
– Demographics
– Knowledge of the domain and of
computers
– Physical ability
– Psychological traits and emotional
feelings
Use Cases
• Used to describe the outwardly
visible requirements
Order Processing Problem
Statement
• Problem Description
– We are developing order processing software for a mail
order company called National Widgets, which is a
reseller of products purchased from various suppliers.
– Twice a year the company publishes a catalog of
products, which is mailed to customers and other
interested people.
– Customers purchase products by submitting a list of
products with payment to National Widgets. National
Widgets fills the order and ships the products to the
customer’s address.
– The order processing software will track the order from
the time its is received until the product is shipped.
– National Widgets will provide quick service . They
should be able to ship a customer’s order by the
fastest, most efficient means possible.
– Customers may return items but will sometimes pay a
fee.
• Assumptions
– An electronic interface, such as web, would be good for
some customers.
Identifying System
Boundaries
• Finding out what things are inside –
you have to worry about creating
them, and what things are outside –
you don’t have to create them but
have to worry about interfacing with
them.
What is the boundary of this
system?
National widgets will need to ship orders to customers.
Shipping needs to include packaging and labeling
orders, weighing them, and determining postage based
on shipping method, speed of delivery, insurance,
weight, destination, and so on.
Should our system include the printing of mailing

labels and calculating postage?
Identify actors and the use cases

to determine the system boundary
Actors
• Actors are anything that interface
with our system.
– people, other software systems,
hardware devices, etc.
• Each actor defines a particular role.
• Actors are outside the system.
• Each entity outside our system may
be represented by one or more
actors.
Identifying Actors
• Ask the following questions:
– who uses the system?
– who installs the system?
– who starts up the system?
– who maintains the system?
– who shuts down the system?
– what other systems use the system?
– who gets information from this system?
– who provides information to this system?
– does anything happen automatically at a
preset time?
Sample Actors
• Customer – a person who orders products from
National Widgets
• Customer Rep – an employee of National Widgets
who processes customer requests
• Shipping company – such as DHL, FedEX
• Clerk – an employee of NW who packages, labels,
and ships orders
• Inventory system – software that tracks the
company inventory
• Accounting system – software that keeps the
company books
Use Cases
• Things actors want the system to do.
• Represent system functions
• A use case is almost always started by
an actor.
• It represents the interaction between
the actor and the system.
– User’s action and the system’s
reaction
Developing Use-Case Models
of Systems
• A use case is a typical sequence of actions
that a user performs in order to complete a
given task
– The objective of use case analysis is to model the
system
… from the point of view of how users interact with
this system
… when trying to achieve their objectives.
– A use case model consists of
• a set of use cases
• an optional description or diagram indicating
how they are related
Use cases
• In general, a use case should cover
the full sequence of steps from the
beginning of a task until the end.
• A use case should describe the user’s
interaction with the system ...
– not the computations the system
performs.
• A use case should be written so as to
be as independent as possible from
any particular user interface design.
• A use case should only include
Use Cases
• Ask the following questions:
– what functions will the actor want from the system?
– does the system store information? what actors will create,
read, update, or delete (CRUD operations) that information?
– does the system need to notify an actor about changes in its
internal state?
– are there any external events the system must know about?
what actors inform the system about these events?
• Other kind of use cases to consider are:
– start-up, shut down, diagnostics, installation, training, and
changing a business process.
– Maintenance – will you have to shut it down or can you do
your maintenance on it while still using it?
• When considering these and other questions,
determine whether these functions are handled by
our system?
Use Cases
• For each of the identified requirements
ask:
– Are these requirements necessary for this
system?
– Are these requirements something this system
would logically do?
– Can these requirements be handled by one of
the current actors? In other words, is someone
else responsible for them?
– Are these requirements something our
customers would expect our system to do?
Order Processing Use Cases
• From a customer – place order, send catalog, get
status on order, return product, cancel order,
register complaint
• From a customer rep – place order, send catalog,
get status on order, return product, cancel order,
register complaint
• To shipping companies – packages ready for
delivery
• From clerk – print mailing labels, calculate
postage
• To inventory system – give product information,
update product quantities
• from inventory system – back-ordered items
USE CASE
If DIAGRAM
the use case
diagram is too big or
messy, we can
create several use
case diagrams.
Each diagram might

represent a major
area of functionality
or we could have
one per actor.
At various points in
the project we need
to compare these
diagrams to remove
redundancies and to
keep them
Scenarios
• Each use case must include details about
what has to be done to accomplish the
functionality of the use case.
– basic functionality
– alternative paths
– error conditions
– pre-condition: a condition that must be true
before starting
– post-condition: a condition that must be true
at the end.
• The use case may contain conditionals,
branching, and loops.
Scenarios
• A scenario is an instance of a use
case
– It expresses a specific occurrence of the
use case
• a specific actor ...
• at a specific time ...
• with specific data.
Scenarios
• Scenarios are written from an actor’s point
of view.
• Each scenario is a sequence of events that
describes the functionality of the use case.
• It can be thought of as a list of steps to go
through to accomplish the use case.
• The primary scenario is written as if
everything goes right.
• There must be one primary scenario for
each use case.
• Use cases are built iteratively.
Place Order Use Case
Pre-condition: 1. The customer will enter
A valid user has logged into credit card payment
information.
the system
2. The customer will select
Flow of Events: submit.
Basic Path: 3. The system will verify
1. The use case starts the information, save
when the customer the order as pending,
selects place order. and forward the
2. The customer enters payment information to
his/her name and the accounting system.
address 4. When payment is
3. If the customer enters confirmed, the order is
only the zip code the marked Confirmed, an
system will supply the order ID is returned to
city and the state. the customer, and the
4. The customer will enter use case end.
product codes for
desired products. lternative Path:
5. The system will supply a
product description and
Showing Alternatives with
Branching
• Find Order Use Case
Flow of Events:
– The user may enter an order ID, customer ID,
or customer name.
– The user will press find.
– If the user entered an order ID
a) The system will display the order.
4. If the user entered a customer name or
customer ID
a) The system will return a list of all orders for
that customer.
b) The user will select one order from the list
c) The system will display the order
Repetition
Flow of Events: 1. The customer will enter
credit card payment
Basic Path:
information.
– The use case starts when
the customer selects place
submit.
order.
– 3. The system will verify the
The customer enters
information, save the order
his/her name and address
as pending, and forward
– If the customer enters only the payment information to
the zip code the system will the accounting system.
supply the city and the
4. When payment is
state.
confirmed, the order is
– The customer will enter marked Confirmed, an
product codes for desired order ID is returned to the
products. customer, and the use case
– For each product code end.
entered
• The system will
supply a product
description and the
price for each item.
Repetition
credit card payment
Basic Path:
information.
– The use case starts when
submit.
order.
– 3. The system will verify the
The customer enters
– If the customer enters only the payment information to
4. When payment is
state.
– The customer will enter marked Confirmed, an
– While the customer end.
enters product codes
• The system will supply a
the price for each item.
• The system will add the
Alternative Paths
credit card payment
Basic Path:
information.
1. The use case starts when
submit.
order.
3. The system will verify the
2. The customer enters
3. If the customer enters only the payment information to
4. When payment is
state.
4. The customer will enter marked Confirmed, an
5. While the customer enters end.
product codes
• The system will supply a lternative Paths
the price for each item.
At any time before selecting
• The system will add the
Other alternative scenarios
• Is there any difference between the
way the customer and the sales rep
interact with the system?
• Are there any other error conditions?
– an order arrives that is missing a
payment.
– an order arrives that is missing a
shipping address.
Pre-condition:
Flow of Events:
Basic Path:
Alternative Paths:
Post Condition:
Special Requirements:
The system must always respond to the
user input within one second.
Presentation Styles
• Cancel Order Use Case
• Primary Scenario
When the customer rep receives a
request to cancel order, the
customer rep finds the order in the
system and marks it cancelled. Then
a request is sent to the accounting
system to credit the customer’s
account.
Presentation Styles
• Cancel Order Use Case
• Primary Scenario
1. The use case begins when a customer rep
receives a request to cancel order.
2. The customer rep enters the order ID
3. The customer rep presses find
4. The system will display the order
5. The customer rep presses cancel-order
6. The system marks the order cancelled
7. The accounting system is notified to credit the
customer’s account and the use case ends.
Secondary Scenarios
• To completely define a use case we
need to identify scenarios for
alternative paths and scenarios for
error conditions
• These can be added to the basic path
or written as secondary scenarios.
Place Order Secondary
Scenarios
• Payment not there
• order incomplete
• order gets lost
• customer can’t login
• shipping address is incomplete
• product code does not match actual products
• product no longer carried
• payment bad
• customer pays by check
• customer sends order by mail
• customer phones in order
Dependencies
<<extend>> and <<include>>
Stereotypes
• Extend dependencies are used when we have an
optional sequence of events we want to include in
the use case.
• Used to make optional interactions explicit or to
handle exceptional cases.
• By creating separate use case extensions, the
description of the basic use case remains simple.
• A use case extension must list all the steps from
the beginning of the use case to the end.
– Including the handling of the unusual situation.
Dependencies
<<extend>> Stereotypes
• Determine what should be added and where it
should be added.
• More than one use case can extend from the same
point.
• More than one extension can be executed from the
same point.
• When the extension point is reached, the
conditions for all the extending use cases for that
point are evaluated.
• Every extension with a true condition is executed.
• The order of evaluation of the extending use cases
is undefined.
credit card payment
Basic Scenario:
information.
1. The use case starts
when the customer
submit.
selects place order.
3. The system will verify
2. The customer enters
the information, save
his/her name and
the order as pending,
address
and forward the
3. The customer will enter payment information to
product codes for the accounting system.
desired products.
4. When payment is
4. The system will supply a confirmed, the order is
product description and marked Confirmed, an
the price for each item. order ID is returned to
5. The system will keep the customer, and the
running
We need total
to add a of items
requirements to: use case end.
ordered
2. offer salesason
they are
various Place Order
entered.
merchandise on various items
___________
Sale Item , before step 5
3. offer special discounts to Frequent customer , before step 6
frequent customers
Extending Use Case Seasonal
Sale Price
If product in Seasonal sale list then
Sale Item Extension
1. The system will get the sale discount
for the product
2. The system will display the discount on
the order
3. The system will calculate a discount
amount
4. The system will subtract the discount
amount from the order total
Extending Use Case Frequent
Customer Discount
If the customer in Special Customer list
then
Special Customer Extension
1. The system will get the customer
discount
the order
3. The system will calculate the discount
amount
Extending Use Case Overstock
Product Sale
If product in Overstock list and amount
of product on hand > maximum
stock level them
Sale Item Extension
1. The system will get the sale discount
for the product
the order
3. The system will calculate a discount
amount
If the product is
overstocked and is
also on sale then it
will be discounted
twice!
Is the order
important?
<<include>>
• Reuse the common behavior
• Allow one to express commonality between

several different use cases.
• Inclusions are included in other use cases

– Even very different use cases can share
sequence of actions.
– Enable you to avoid repeating details in
multiple use cases.
• Represent the performing of a lower-level task

with a lower-level goal.
<<include>>
• Identify common steps
• Put them in a use case and give it a
name
• Now remove these steps from the
original use cases and replace them
with a reference to the new use case.
• It is important to note that the Using
use case is no longer complete by
itself.
Find Order Use Case
Flow of Events:
1. The user may enter an order ID, customer ID,
or customer name.
2. The user will press find.
3. If the user entered an order ID
a) The system will display the order.
4. If the user entered a customer name or
customer ID
a) The system will return a list of all orders for that
customer.
b) The user will select one order from the list
c) The system will display the order
Cancel Order Use Case
– The use case begins when a customer rep
– The customer rep enters the order ID
– The customer rep presses find
– The system will display the order
– If the order status is Confirmed
a) The order is marked Cancelled
b) The accounting system is notified to credit
the customer’s account and the use case
ends.
6. If the order status is Shipped
a) The customer is notified of NW’s return
policy
Cancel Order Use Case
– The use case begins when a customer rep
– <<include>> Find Order.
– If the order status is Confirmed
a) The order is marked Cancelled
b) The accounting system is notified to credit
the customer’s account and the use case
ends.
4. If the order status is Shipped
a) The customer is notified of NW’s return
policy
Generalization
• Much like super-classes in a class diagram.
• A generalized use case represents several
similar use cases.
• One or more specializations provides
details of the similar use cases.
• Mostly used between actors.
• Generalization between actors means that
one actor fills the same roles as another
actor.
• It also may fill additional roles.
Example of generalization, extension
and inclusion
Open file
Ordinary User
Open file by Open file by

typing name browsing
«extend» «include»
Attempt to open file

that does not exist Browse for file
System
Administrator
Example description of a
use
Use case: Open file
case

Related use cases:
Generalization of:
• Open file by typing name
• Open file by browsing

Steps:
Actor actions System responses
1. Choose ‘Open…’ command 2. File open dialog appears
3. Specify filename
4. Confirm selection 5. Dialog disappears

Example (continued)
Use case: Open file by typing name

Related use cases:
Specialization of: Open file

Steps:
3a. Select text field
3b. Type file name
4. Click ‘Open’ 5. Dialog disappears

Example (continued)
Use case: Open file by browsing

Related use cases:
Specialization of: Open file
Includes: Browse for file

Steps:
3. Browse for file
4. Confirm selection 5. Dialog disappears

Example (continued)
Use case: Attempt to open file that does not exist

Related use cases:
Extension of: Open file by typing name

3a. Select text field
3b. Type file name
4. Click ‘Open’ 5. System indicates that file
does not exist
6. Correct the file name
7. Click ‘Open’ 8 Dialog disappears

Example (continued)
Use case: Browse for file (inclusion)

Steps:
1. If the desired file is not displayed, 2. Contents of directory is
select a directory displayed
3. Repeat step 1 until the desired file is
displayed
4. Select a file

Activity Diagram
User Interface

Requirement Engineering

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Requirement Engineering

Caricato da

Copyright:

Formati disponibili

Use Case Modeling

Chapter 7 of the Text Book

Chapter 4, 7, and some

• Vision – focus on why

Rate of Growth Comparartive Costs

© Lethbridge/Laganière Chapter 4: Developing

© Lethbridge/Laganière Chapter 4: Developing

3. Categories constraining the project plan and

© Lethbridge/Laganière Chapter 4: Developing

• Stake holders – different people who would

Should our system include the printing of mailing

Identify actors and the use cases

Each diagram might

• Allow one to express commonality between

• Inclusions are included in other use cases

• Represent the performing of a lower-level task

Open file by Open file by

Attempt to open file

Potrebbero piacerti anche