CHAPTER THREE Use case diagrams

AN OVERVIEW OF REQUIREMENTS ELICITATIONS

In requirements engineering, requirements elicitation is the
practice of researching and discovering the requirements of a
system from users, customers, and other stakeholders.
The practice is also sometimes referred to as "requirement
gathering".
Before requirements can be analyzed, modeled, or specified they
must be gathered through an elicitation process.
Requirements elicitation is a part of the requirements engineering
process, usually followed by analysis and specification of the
requirements.
ELICITATION TECHNIQUES
Brainstorming
Document analysis
Focus Group
Interviews
Observation
Prototyping
Survey/questionnaire
CHARACTERISTICS OF SOFTWARE REQUIREMENT
SPECIFICATION
Correct
Complete
Unambiguous
Verifiable
Consistent
 Modifiable
Traceable
TYPES OF SOFTWARE SYSTEM REQUIREMENTS
There are two types of software system
requirement,
Functional Requirements: are statements of services the
system should provide,
how the system should react to
particular inputs, and
how the system should behave in
particular situations.
Non functional requirements: These are requirements
that are not directly concerned with the specific services
delivered by the system to its users.
Nonfunctional requirements can be elicited by
investigating the following issues.
User interface and human factors
Documentation
Hardware considerations
Performance characteristics
Error handling and extreme conditions
Quality issues
System modifications
Physical environment
Security issue
Resource issue
REQUIREMENTS ELICITATION ACTIVITIES
A use case describes how a user uses a system to accomplish a
particular goal.
A use case diagram consists of
 the system (what is being described? ),
The actors (who is using the system?) and
 the use cases (what do the actors want to achieve? )
In brief, the purposes of use case diagrams can be said to be as
follows −
Used to gather the requirements of a system.
Used to get an outside view of a system.
Identify the external and internal factors influencing the system.
Show the interaction among the requirements are actors.
IDENTIFYING ACTORS
The operating environment of a software system consists of the
users, devices, and programs that the system interacts with. These
are called actors.
A UML actor icon is a stick figure:
Types of actors:
primary - a user whose goals are fulfilled by the
system
supporting - provides a service (e.g., info) to the
system
offstage - has an interest in the behavior but is not
primary or supporting, e.g., government •
importance: ensure all interests (even subtle) are
identified and satisfied
HEURISTICS OF FINDING ACTORS
Which user groups require help from the
system to perform their tasks?
Which user groups are needed to execute
the system„s most obvious main functions?
Which user groups are required to perform
secondary functions, such as maintenance and
administration?
Will the system interact with any external
hardware or software system?
USE CASE DIAGRAM NOTATIONS
DESCRIPTION OF USE CASE COMPONENTS
Actor
Actors are usually individuals involved with the system defined according to
their roles. The actor can be a human or other external system.
Use Case
A use case describes how actors uses a system to accomplish a particular
goal. Use cases are typically initiated by a user to fulfill goals describing the
activities and variants involved in attaining the goal.
Relationship
The relationships between and among the actors and the use cases.
System Boundary
The system boundary defines the system of interest in relation to the world
around it.
STRUCTURING USE CASES
UML defines three stereotypes of association between Use Cases:
<<include>> Use Case
The time to use the <<include>> relationship is after you have completed
the first cut description of all your main Use Cases.
You can now look at the Use Cases and identify common sequences of user-
system interaction.
<<extend>> Use Case
An extending use case is, effectively, an alternate course of the base use
case.
The <<extend>> use case accomplishes this by conceptually inserting
additional action sequences into the base use-case sequence.
Abstract and generalized Use Case
The general use case is abstract. It can not be instantiated, as it contains
incomplete information. The title of an abstract use case is shown in italics.
Example: restaurant (the business system) and its primary actors.
Exercise: online shopping system.
TEXTUAL DESCRIPTION OF USE CASES
It is helpful to have our use cases textual
description.
For the textual description of a use case, we use a
template composed of six fields
 Name:
The name of the use case is unique across the system so that
developers (and project participants) can unambiguously refer
to the use case.
Participating actors:
Participating actors are actors interacting with the use case.
Entry conditions:
Entry conditions describe the conditions that need to be
satisfied before the use case is initiated.
Flow of events :
The flow of events describes the sequence of
interactions of the use case, which are to be numbered
for reference.
Exit conditions:
Exit conditions describe the conditions satisfied after
the completion of the use case.
Quality requirements:
Quality requirements are requirements that are not related to
the functionality of the system. These include constraints on the
performance of the system, its implementation, the hardware
platforms it runs on, and so on.
Use Case Name: AddUserAccount
Participating Actor: Administrator
Description: Allow the administrator to add accounts.
Entry conditions: Administrator should log in.
Flow of Events:
1. The administrator initiates “Add User Accounts” use case.
2. The System displays the Create User form.
3. The administrator fills in the details of the new user like name, Id,
role, user name, and password.
4. The system checks the information filled and acknowledges.
[Alternate 1]
Exit Condition: The account will be added.
Alternate Flow 1 [if the administrator fills the existed user name/if the
administrator fills wrong data]
1.1 The system displays the wrong message dialogue and resets the
Create User Account form empty.
Quality requirements
The system will create a new account with in reasonable amount of time depending
on the system work load.
USE CASE SCENARIOS
A use case is an abstraction that describes all
possible scenarios involving the described
functionality.
A scenario is an instance of a use case describing
a concrete set of actions.
Scenarios are used as examples for illustrating
common cases; their focus is on understandability.
Use cases are used to describe all possible cases;
their focus is on completeness.
We describe a scenario using a template with three
fields:
Name:
The name of the scenario enables us to refer to it unambiguously.
The name of a scenario is underlined to indicate that it is an
instance.
Participating actor instances:
The participating actor instances field indicates which actor
instances are involved in this scenario. Actor instances also have
underlined names.
Flow of events :
The flow of events of a scenario describes the sequence of
events step by step.
Use Case Name: AddUserAccount
Participating Actor: Abebe
Description: Allow Abebe to add accounts.
Entry conditions: Abebe should log in.
Flow of Events:
1. Abebe initiates “Add User Accounts” use case.
2. The System displays the Create User form.
3. Abebe fills in the details of the new user like name, Id, role, user
name, and password.
4. The system checks the information filled and acknowledges.
Exit Condition: The account will be added.
MANAGING REQUIREMENTS ELICITATION
Use case modeling by itself does not
constitute requirements elicitation.
There are methods used to elicit information
from the users and negotiating an agreement
with a client.
Negotiating Specifications with Clients: Joint Application
Design
Maintaining Traceability
Documenting Requirements Elicitation
NEGOTIATING SPECIFICATIONS WITH CLIENTS: JOINT
APPLICATION DESIGN
Joint Application Design (JAD) is a requirements method
developed at IBM at the end of the 1970s.
 Its effectiveness lies in that the requirements elicitation work is
done in one single workshop session in which all stakeholders
participate.
Users, clients, developers, and a trained session leader sit
together in one room to present their viewpoints, listen to other
viewpoints, negotiate, and come to a mutually acceptable solution.
The outcome of the workshop, the final JAD document, is a
complete requirements specification document that includes
definitions of data elements, work flows, and interface screens.
MAINTAINING TRACEABILITY
Traceability is the ability to follow the life of a
requirement.
Traceability enables developers to show that the
system is complete
testers to show that the system complies with its
requirements
designers to record the rationale behind the
system, and
maintainers to assess the impact of change.
The simplest approach to maintaining traceability is to
use cross-references among documents, models, and code
artifacts.
Each individual element (e.g., requirement, component,
class, operation, test case) is identified by a unique
number. Dependencies are then documented manually as a
textual cross-reference containing the number of the source
element and the number of the target element.
Tool support can be as simple as a spreadsheet or a
word processing tool for simple systems or use specialized
database tools for large scale system.
DOCUMENTING REQUIREMENTS ELICITATION
The results of the requirements elicitation and the
analysis activities are documented in the
Requirements Analysis Document (RAD).
This document completely describes the system in
terms of functional and nonfunctional requirements.
The audience for the RAD includes the client, the
users, the project management, the system analysts
(i.e., the developers who participate in the
requirements), and the system designers (i.e., the
developers who participate in the system design).
REQUIREMENT VALIDATION
Validation is the process of confirming the completeness and
correctness of requirements.
Validation also ensures that the requirements:
 achieve stated business objectives,
meet the needs of stakeholders, and
 are clear and understood by the developers.
Validation is essential to identification of missing requirements
and to ensure that the requirements meet certain quality
characteristics.
 REQUIREMENT VALIDATION
Ad-hoc: The reviewers simply attempts to find as many defects as possible
by examining the document using the skills and knowledge they have.
Checklist-based: the reviewer is given a checklist with questions that are to
be answered during the review.
The questions shall draw the attention of the reviewer to some aspects of the inspected
document that are often found defective.

Perspective-based reading: When using the perspective-based reading

technique reviewers use different roles or points of view when reviewing.
For example, reviewing as a tester, reviewing as a designer, etc. Each role has scenarios that
include questions and activities that tell the reader how to review.

Scenario-based:
Defect-based reading: To use the defect-based reading technique we need to create
a model of possible defects in requirements documents.
 For each defect class from the model (e.g. the class of data type inconsistencies, incorrect functions,
and/or missing or ambiguous functions), we develop a set of questions that would characterize the
defect class.
 While reading the document, the reviewer tries to answer the questions and find defects in the
document.
ASSIGNMENT ONE
 Functional requirement
Non- Functional requirements
Use Case diagram
Use case Description
 use case Scenarios