Use-Cases in Software Englineering

8/13/2019 Use-Cases in Software Englineering

1/20

USE CASES


2/20

Developing Use-cases

What is Use-Case????
http://www.consult-me.co.uk/first-requirements-analysis-cartoon.gif


3/20

Use-Cases

A use case is a methodology used in system analysisto identify, clarify, and organize systemrequirements.

Use cases are a way of decomposing systemfunctionality into smaller chunks

It forces decisions about scope - Use cases are only

written for functionality within the scope.A use case specifies a complete system functionality


4/20

Origin of Use Case

Developed by Ivar Jacobson and colleaguesOriginated from telecommunications work from 1967onwards

Object-based, using the concept of building systemsfrom blocks

Found in Jacobsons book Object -OrientedSoftware Engineering (OOSE), 1992

Complete set of use cases describes the behaviourrequired of the system


5/20

Purpose of Use Cases

Use cases are used to scope system functionality

They help to produce a more concise, less ambiguous statement of therequirements.

They will be used as a platform to deeper understanding

Use cases will be developed into example interactions - scenarios

They form the basis for the system test plan


6/20

Actors

Anything that communicates with the system

The systemEverything that the project has control over

An actor is a role that user plays with respect to thesystem.

A person, organization, or external system that

interacts with the application that we are currentlydeveloping could be actors to our system

Actor uses Use Cases.


7/20

Role(EmployeeCustomer

Guest)System

(Accounting PackageProduct Inventory

Bar System)

Device(Drink Dispenser

Cash Register Door Lock)

Kinds of Actors


8/20

Role of An Actor In Use Cases

Primary Actor

Initiator actor

Active

Initiate activity with thesystem

Get some response inreturn

Secondary ActorParticipating actorPassiveDont initiate activitywith the system

Available when thesystem need themFulfill the needs of aprimary actor


9/20

Identification of Use Cases

Describes the sequence of events of an actor using asystem to complete a process, it means multiple

events form a use caseName of the use case must start from the verb

e.g.: submit form, submit fee, generate result, buyitem etc.


10/20

UML Notations for Use Cases

Actor

Use Case

System boundary a box with the use cases inside

and the actors outsideAssociations straight lines or arrows going fromactors to the use casesRelationships Dotted lines or arrows going from oneuse case to another

Customer

WithdrawCash


11/20

Customer withdraws cash from an ATM

Pilot and co-pilot perform pre-flight check

Employee supplies hours workedCustomer buys goods at a supermarket

Dealer deals cards in bridge game

Inventory reordering applied in retail store

Engineer tests electronic ignition in car

Sample use case names

Use CaseA use case is a related sequence of interactions betweenone or more actors and the system


12/20

Use Case Example - 1

Super Market System


13/20

Customer Manager

ProductDatabase

Supermarket System

Buy Goods

Return Goods

Produce CashFlow Report

Update Stock

Use Case DiagramDecide who the users of our system are to be: ACTORS

Decide what they wish the system to do: USE CASES

Use cases replace a requirement specification

Write use cases from a problem statement

Or translate a requirement specification into use cases


14/20

Use-cases Example II

Online Library Management System


15/20

Students and University Staff can register himself

He/She can borrow/return resources from the libraryVarious Books/Resources can be searched

Librarian can add / discard a book

Library management System


16/20Use-case diagram of Library System


17/20

Limitations of Use Cases

Use Cases cannot describe non-functionalrequirements like

Reliability

Standards compliance

Legal requirements etc.


18/20

Impact of Requirements Issues on Projects

Major factors why projects are not fully successful:12.8% = lack of user input12.3% = incomplete requirements and specifications

11.8% = changing requirements and specifications2001 Survey of top risks facing e-projects66% = unstable, constantly changing requirements55% = poor requirements specification

42% = client approval delays, changes, poorcommunication


19/20

Impact of Requirements Issues on Projects

30-40% of software project effort is rework

About 50% of software defects originate inrequirements.

Reducing requirement errors can increaseproductivity.


20/20

The Problem of MisunderstoodScope

Scope describes the range of a system; whats inside, whats outside,what it does and what it doesnt do

Where scope is not stated, users and developers will have differinginterpretations

Badly chosen or misunderstood scope is a major cause of dissatisfiedusers and frustrated developers

Use-Cases in Software Englineering

Documents

Transcript of Use-Cases in Software Englineering