TERMS

 User story: one short sentence in the everyday language of the end user
that states what a user does as part of his or her work
 Acceptance criteria: features that must be present in the final system
for the user to be satisfied
 Use case: An activity that the system performs in response to a request
by a user.
 User goal technique: A technique to identify use cases by determining
what specific goals or objectives must be completed by the system for the
user
 Event decomposition technique: A technique to identify use cases by
determining the business events to which the system must respond.
 Actor: an external agent; a person, group or external system that
interacts with the system by supplying or receiving data.
 System controls: Checks or safety procedures to protect the integrity of
the system and data.
 Perfect technology assumption: The assumption that a system runs
under perfect operating and technological conditions.
 Use case diagram: The UML model used to illustrate use cases and their
relationship with actors.

Explain why identifying user stories and use

cases is the key to defining functional
requirements
 User stories and use cases form the basis for the list of functions the
system needs to carry out.
 They provide a structured way to capture and understand how users will
interact with the system.
 These two concepts focus on the goals of the user and ensure functional
requirements are tied directly to what users need, rather than being overly
technical or abstract.


Write user stories with acceptance criteria

 User stories are favoured by highly agile system development
methodologies.
 A user story is used to document the functional requirements quickly and
less formally than traditional requirements modelling by focusing on who,
what, and why for each function.
  Acceptance criteria focus on functionality, not on features or user-interface
design.

Describe the two techniques for identifying

use cases
Use cases represent detailed scenarios that describe how users will interact with
the system to achieve their goals.
Two techniques recommended for identifying use cases are the User goal
technique and the event decomposition technique.

Describe the user goal technique for identifying use

cases
The user goal technique requires you to ask users to describe their goals for
using the new updated system.
The user goal technique for identifying use cases includes these steps:
1. Identify all potential users for the new system
 2. Classify all the potential users in terms of their functional role (e.g.,
shipping, marketing, sales)
3. Further classify potential users by organizational level (e.g., operational,
management, executive).
4. Interview each type of user to determine the specific goals they will have
when using the new system. Start with goals they currently have then
probe for more innovative functions they think would add value.
5. Create a list of preliminary use cases organized by type of user.
6. Look for duplicates with similar use case names and resolve
inconsistencies
QUESTION: WHAT ARE SOME EXAMPLES OF USERS WITH DIFFERENT
FUNCTIONAL ROLES AND A DIFFERENT OPERATIONAL LEVELS?
Functional roles could be shipping, marketing, and sales.
Operational levels could be bookkeepers, factory workers, clerks
Different operational levels would be middle management and then executive
management.
QUESTION: WHAT IS THE OVERACHING OBJECTIVE OF ASKING USERS
ABOUT THEIR SPECIFIC GOALS?
The overarching objective is to identify how a system can improve the user’s
performance and productivity. Subsidiary goals could include streamlining tasks
the users currently perform or enabling the user to perform new tasks that are
not possible.

QUESTION: HOW MANY TYPES OF USERS CAN HAVE THE SAME USER
GOALS FOR USING THE SYSTEM?
There is no limit. Users from different departments can access the same use
cases and they can have the same user goals.

Describe the event decomposition technique for

identifying use cases
The most comprehensive technique for identifying use cases is the event
decomposition technique.
The technique identifies all the business events that will cause the information
system to respond, and each event leads to a use case. Starting with business
events helps the analyst define each use case at the right level of detail.
An event occurs at a specific time and place, can be described, and should be
remembered by the system. Events triggers all processing data the system does,
so listing events and analysing them defines system requirements by identifying
use cases.
There are 3 types of events:
 1. External events
2. Temporal events
3. State events
An External event is an event that occurs outside the system initiated by an
external agent or actor.
To identify the key external events, the analysts first try to identify all the actors
that might want something from the system
These events lead to important transactions that the system must process.
For example, a customer may want to place an order for one or more products.
The customer also might want to make a return or pay an invoice on for an order.
External events such as these begin to define what the system needs to be able
to do
A temporal event occurs because of a reaching a point in time. For example, a
payroll system produces a paycheck every two weeks.
These are different to external events in that the system should automatically
produce the required report or exception reports.
A state event occurs when something happens inside the system that triggers
the need for processing. State events are also called internal events. For
example, once a product is sold, its stock count is decreased and drops below a
reorder point, it is necessary to reorder.
State events often occur because of external events.

QUESTION: WHAT IS AN ELEMENTARY BUSINESS PROCESS (EBP)?

The appropriate level of detail for identifying use cases is one that focuses on
elementary business processes (EBPs)
An EBP is a task that is performed by a person in response to a business event,
adds business value, and leaves the system in a stable state
QUESTION: WHY IS THE EVENT DECOMPOSITION TECHNIQUE
CONSIDERED MORE COMPREHENSIVE THAN THE USER GOAL
TECHNIQUE?
The event decomposition technique not only looks at user-initiated events, but
has additional methods of also considering 3 types of events during the
identification of use cases, such as external events, temporal events, and state
events
QUESTION: EXPLAIN HOW THE EVENT DECOMPOSITION TECHNIQUE
HELPS IDENTIFY USE CASES AT THE RIGHT LEVEL OF ANALYSIS?
It focuses on identifying the events to which the system must respond and then
determining how to respond. When a user triggers several events, the system
must respond with several use cases. Describing the system in terms of events
keeps the focus of the system on the business requirements at the elementary
business process. The result is a list of use cases triggered by business events at
the right level of analysis.\
QUESTION: WHAT ARE SYSTEM CONTROLS, AND WHY ARE THEY NOT
CONSIDERED PART OF THE USERS FUNCTIONAL REQUIREMENTS?
Some events are important but do not directly concern users or transactions.
Such events typically involve design choices or system controls. The analyst
should ignore this at the start and focus on it later for design.
Most of these events are checks or safety procedures put in place to protect the
integrity of the system or database, such as backing up the data daily.
These controls are important and will edit the system during design. These
controls add details to the requirements model that users are not typically very
concerned about.
QUESTION: WHAT IS THE PERFECT TECHNOLOGY ASSUMPTION?
It is a technique which helps decide which events apply to controls to assume
that the technology is perfect.
The assumption states that events should be included during analysis only if the
system would be required to respond under perfect conditions.
Pretending the technology is perfect allows analysts to eliminate events like
“back up the database” as they assume the data will never disappear.
These controls are added later during design because obviously technology is not
perfect
QUESTION: WHAT ARE THREE EXAMPLES OF EVENTS THAT OUR SYSTEM
CONTROLS IN A TYPICAL INFORMATION SYSTEM THAT SHOULD NOT BE
INCLUDED AS A USE CASE BECAUSE OF THE PERFECT TECHNOLOGY
ASSUMPTION?
 System crash requires database recovery
 Time to back up the database
 Time to require the user to change the password
 Apply the user goal technique to identify
use cases

Apply the event decomposition technique to

identify use cases
To summarize, the event decomposition technique for identifying use cases
include these steps:
1. Consider the external events in the system that require a response from
the system

2. For each external event, identify the use case that the system requires
3. Consider temporal events that require a response from the system
 4. For each temporal event, identify and name the use case that the system
requires and establish the point of time that will trigger the use case.
5. Consider the state events that the system might respond to. Particularly if
it’s a real-time system in which devices or internal state changers trigger
use cases
6. For each state event, identify and name the use case that the system
requires and then define the state change
7. When events and use cases are defined, check to see if they are required
as part of analysis by using the perfect technology assumption. Do not
include events that involve system controls such as login, logout, change
password, and backup or restore the database, as these are put in as
system controls.

Describe the notation and purpose for the

use case diagram
A brief use case description is a one-sentence description that provides a quick
overview of a use case.

An automation boundary redefines the border between the computerised

portion of the application and the people operating the application. It is shown as
a rectangle containing the use case.
In UML a person who uses the system is called an actor. An actor is always
outside the automation boundary of the system but may be part of the manual
portion of the system. An actor can also be another system or device it received
services from.
QUESTION: WHAT IS THE <<INCLUDES>> RELATIONSHIP BETWEEN TWO
USE CASES?
During development of a use case, it becomes apparent that one use case might
use the services of another use case.
For example, while filling the shopping cart, the customer might also search for
an item, view comments, and view accessories.
Therefore, one use case <<uses>> or “includes” another use case.
The relationship between these use cases is denoted by the dash connecting line
with the arrow that points to the use case that is included.
The word includes is denoted in guillemets in the diagram to refer to a
stereotype in UML.
Draw use case diagrams by actor and by
subsystem.
The steps to develop use case diagrams are:
 Identify all the stakeholders and users who would benefit by having a use
case diagram.
 Determine what each stakeholder or user needs to review in a use case
diagram. A diagram might be produced for each subsystem, for each type
of user, for use cases with the <<includes>> relationship, and for use
cases that are of interest to specific stakeholders.
 For each potential communication need, select the use cases and actors to
show and draw the use case diagram.
 Name each use case diagram and then know how and when the diagram
should be used to review use cases with stakeholders and users.