Download - Writing Effective Use Cases

EFFECTIVE USE-CASEWRITING

Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s CLASSROOM

BITS PilaniOff-Campus Work-Integrated Learning Programmes

AGENDA

� Requirements Engineering

� What is a Use-Case?

� Sections in a Use-Case

� Goals & Scope of Use-Case

4 Steps to Use-Cases� 4 Steps to Use-Cases

� Supplementary Specification

9/22/2008

2

Object Oriented Analysis & Design

ACKNOWLEDGEMENT

This part of the lecture is based on:

Integrated Requirements Engineering: A Tutorial

Ian Sommerville, Lancaster University

International Requirements Engineering International Requirements Engineering

Conference (RE ’04).

A copy of this could be got from:

IEEE Software January- February 2005

9/22/2008

3


MOTIVATION FOR REQUIREMENTS

ENGINEERING

� Before any software system is developed:

� We must understand what the system is supposed to do

� How its use can support goals of individuals / organizations

� This involves:

� Understanding Application Domain

� Systems Operational Constraints

� Specific Functionality Required by stake-holders

� Essential characteristics like performance, security, reliability and dependability

9/22/2008

4


WHAT IS REQUIREMENTS ENGINEERING?

� Requirements Engineering is the structured set of activities which:

� Help develop system understanding

� Identifying stake-holders and needs

� Document system specification for stake-holders and engineers involvedengineers involved

� Challenges:

� Numerous and distributed stake-holders

� Varying and conflicting goals

� Difficulties in Articulating these goals

9/22/2008

5


RELATIVE COSTS OF FIXING SOFTWARE

FAULTS200

9/22/2008

6


Requirements Specification Planning Design Implementation Integration Maintenance

1 2 3 4

10

30

THE FUNDAMENTAL PROCESS

DISCLAIMER

RE varies significantly with:

- Size and type of the application developed

- Size and Culture of the companies involved

- The Software Acquisition Process - The Software Acquisition Process

For Instance,

Large Military and Aerospace Projects – Formal

RE

Small Companies – RE is Brainstorming

9/22/2008

7


THE RE ACTIVITY CYCLE

9/22/2008

8


Courtesy: The Integrated Requirements Engineering: A Tutorial

ELICITATION

Process: Identify sources of information about the

system and discover requirements from these

� Identifying stakeholders & user classes

�Customers or Clients

Developers�Developers

�Users - novice users, expert users, occasional

users, disabled users

� Goals & Tasks

�Focus on Problem domain

�And needs of stakeholders

� Scenarios & Use cases

9/22/2008

9


ELICITATION -TECHNIQUES

� Elicitation Techniques

� Traditional techniques

� Questionnaires, surveys, interviews, documents

� Group elicitation techniques

� Prototyping

� Model-driven techniques

� Cognitive techniques

� Contextual techniques

� Need for guidance on use of these Techniques

9/22/2008

10



9/22/2008

11



ANALYSIS

Process: Understand the Requirements their overlaps and conflicts

�Enterprise Modeling� Organizational Structure

� Business Rules� Business Rules

� Data Modeling

� Entity-Relationship-Attribute

� Behavioral Modeling

� Functional behavior of Stakeholders.

� Existing

� Required

9/22/2008

12


ANALYSIS [2]

�Domain Modeling

� Abstract description of the world

� Advantage: Requirement reuse within a

domain

Advantage: detailed reasoning about the � Advantage: detailed reasoning about the

domain

�Modeling Non-Functional Requirement

� Difficult to measure and test

�Analyzing Requirement Models

� Requirement animation, automated reasoning

� Knowledge based critique, consistency check

9/22/2008

13



9/22/2008

14



VALIDATION

Process: Go back to system stake-holders and find

out whether requirements are what they really

need

A prototype may be needed to capture A prototype may be needed to capture

requirements depending on the software process

that is followed. Validation of requirements could

be done using a throw-away prototype or through

incremental development

9/22/2008

15



9/22/2008

16



NEGOTIATION

Process: Inevitably, stakeholders’ views will differ,

and proposed requirements might conflict. Try to

reconcile conflicting views and generate a

consistent set of requirements.

Negotiation must be done using techniques like

group discussions whereby all the stake-holders

are in a common platform. This helps in the

emergence of a clear holistic view from the stake-

holders’ end.

9/22/2008

17



9/22/2008

18



DOCUMENTATION AND MANAGEMENT

� Write down the requirements in a way that

stakeholders and software developers can

understand.

� Control the requirements changes that will

inevitably arise.inevitably arise.

� This leads to effective communication of

requirements (Improving Requirements

Engineering Communication in Multiproject

Environments)

9/22/2008

19


OUTCOME OF RE PROCESS

� Statement of Requirements (a.k.a A

Requirements Document) that defines what is to

be implemented

� Research Community argues that, more complete

and consistent a requirement document is more and consistent a requirement document is more

likely that the software would be reliable

� Formal Description Vs Natural Language

Description

� Formal – Complete, Concise yet costly

� Natural Language – Vague, client disputes yet cheap

during changing requirements

9/22/2008

20


AGENDA







9/22/2008

21


WHAT IS A USE-CASE?

“A set of user instances, where each instance is a

sequence of actions a system performs that yields

an observable result of value to a particular

actor”

Actor – Something with a behavior such as person,

computer system etc.

Scenario – Specific sequence of actions and

interactions between actors and system under

discussion (SuD)

9/22/2008

22


ACTORS

� Actors have ‘goals’ in the system

� There are three kinds of actors

� Primary Actor: has user goals fulfilled through

using services of the SuD

� Supporting Actors: provides a service to the � Supporting Actors: provides a service to the

SuD

�E.g. Automated payment authorization

service

� Offstage Actor: has interest in the behavior of

the use-case

�E.g. Government tax Agency

9/22/2008

23


AN ACTOR HAS GOALS; GOALS NAME USE CASES; A USE

CASE HAS SCENARIOS NAMING SUB-USE CASES.

Actor

has

names

SCHEMATIC DIAGRAM

9/22/2008

24


Goal Use case

Scenariocondition

succeed / fail

names

containscalls

Courtesy: Use-Cases in Theory & Practice, Alistair Cockburn

ALISTAIR COCKBURN’S DEFINITION

Use-Case :

Purpose = requirements

Contents = consistent prose

Plurality = multiple scenarios per use case

Structure = semi-formal Structure = semi-formal

9/22/2008

25


KEY POINTS ABOUT USE-CASES

� Use-cases are requirements, primarily functional

requirements

� Use Cases are text documents, not diagrams and

use-case modeling is primarily an art of writing

texts, not drawingtexts, not drawing

� Any use-case must add observable value to an

actor

� Use-Cases are important part of the iterative

planning

� Use-Case realizations drive design

9/22/2008

26


USE CASE TYPES

� Define ‘what’ the system must do (functional

requirements) without deciding ‘how’ it will do it

(design)- Black Box Use-cases

� Formality Types:

� Brief: Terse one-paragraph summary; covers main � Brief: Terse one-paragraph summary; covers main

success scenario

� Casual: multiple paragraphs; cover various scenarios

� Fully dressed: most elaborate; all steps and

variations are discussed in detail (www.usecases.org

format)

9/22/2008

27


AGENDA







9/22/2008

28


ALISTAIR COCKBURN’S TEMPLATE

Run through of Alistair Cockburn’s Template

9/22/2008

29


SECTIONS IN USE-CASE

� Primary Actor

� Principal actor who calls upon system services

to fulfill a goal

� Stakeholders and Interests

� Contract between stakeholders within the � Contract between stakeholders within the

system boundary

� Pre-Conditions / Post-Conditions

� Pre-conditions must always be true before

starting

� Post-Conditions suggest what might be true on

success

9/22/2008

30


SECTIONS IN USE-CASE [2]

� Main Success Scenario (Basic Flow)

� ‘Happy path’ scenario

� Defer all conditional and branching

statements to the extension section

A Scenario could be three types:

�Interaction between actors

�A validation by the system

�A state change by the system

9/22/2008

31



� Extensions (Alternate Flow)

� Indicates all other scenarios or branches, both

success and failure

� These branches are from the main scenario

and hence labeled ‘1a’, ‘3b’ etcand hence labeled ‘1a’, ‘3b’ etc

� At the end of the extension, the scenario

merges back with the main success scenario

� Sometimes a particular extension point might

be quite complex and might be expressed as a

separate use-case

�E.g. ‘Paying by Credit card’

9/22/2008

32



� Special Requirements

� If a non-functional requirements relates

specifically to a use-case then record it with

the use-case

� These are normally qualities like performance, � These are normally qualities like performance,

reliability and usability

� Technology and Data variation list

� ‘How’ something must be done

� Technical constraint imposed by the

stakeholder and hence necessary to capture

9/22/2008

33


INCREASING LEVELS OF PRECISION

� Actor and Goals

� List of Actors and which of their goals the

system would support.

�Use-Case Brief or Main Success ScenarioPursue main success scenario� Pursue main success scenario

� Failure Conditions

� Based on MSS, deliberate all failures that could occur

� Do not worry about Failure handling at this step

� Failure Handling

� How system is supposed to respond to each failure.

� New business rules, new actors and goals could

surface

9/22/2008

34


AGENDA







9/22/2008

35


CHALLENGES IN USE-CASE DISCOVERY

� Tasks can be grouped at many levels of

granularity from one or a few small steps to

enterprise level activities

� We use Elementary Business Processes (EBP) and

Goals as a framework to identify use-casesGoals as a framework to identify use-cases

� Which is a valid use-case?

� Negotiate a Supplier Contract

� Handle Returns

� Log In

All these are valid at different levels �

9/22/2008

36


EBP GUIDELINE

� For requirements analysis focus on use-cases at the level of a Elementary Business Process (EBP)

� Caveat

� Although base-use cases must follow the EBP guideline, there could be sub-use cases which exists at a lower levelguideline, there could be sub-use cases which exists at a lower level

� Actors have goal a EBP use-case is called a user-goal level use-case, this leads to a recommended procedure

1. Find the user goals

2. Define a use-case for each

9/22/2008

37


INVESTIGATING USER GOALS VS. INVESTIGATING

USE-CASES

Identify to the system

Prevent theft, data

corruption

Goal Hierarchy

9/22/2008

38


Log In

Identify to the system

Cashier at PoS Scenario

1. Quickly log-in

2. Capture SalesMain Goal / Base

use-case

Sub-goal

DESIGN SCOPE VS. GOAL LEVEL

(SCOPE VS. LEVEL)

� Scope

� Which system boundary do we mean?

� “Spatial extent” of the system

� Level

� Why do we want this goal?� Why do we want this goal?

� “strategic” vs. “user task” vs. “sub-function”

9/22/2008

39


SCOPE

Dept. 1 Dept. 3Sys. 1

System

9/22/2008

40


Organization

Dept. 2

Sys. 2

C 1 C 2

C 3

Organization

Component

LEVEL

advertise order invoice

project goal

Strategic Goals“White”

“Blue”

9/22/2008

41


set up

promotion

reference

promotion

monitor

promotion

place

ordercreate

invoice

send

invoice

identify

promotion

identify

customer

register user identify

product

User Goals

Subfunctions

“Blue”

“Indigo”

AGENDA




� Design Scope & Goal Level of Use-Case



9/22/2008

42


STEP I – CHOOSING SYSTEM BOUNDARY

Choosing the System Boundary1

9/22/2008

43


-Clarified by defining what is outside

-Once external Actors are identified the

boundary becomes clear

STEP 2 & 3 – FINDING PRIMARY

ACTORS & GOALS


Finding Primary Actors2

3

9/22/2008

44


Finding Goals3

Identify Primary Actors by asking

questions e.g. Who start/stops the

system?

Actors have goals that must be satisfied

by the system

ACTOR- GOAL LIST

9/22/2008 Object Oriented Analysis & Design 45

Courtesy: Applying UML & Patterns, Craig Larman

STEP 4 – DEFINE USE-CASES


Finding Primary Actors2

3

9/22/2008

46


Start use-cases with a verb

CRUD goals into one use-case Manage ‘X’

Finding Goals3

Define Use-Cases4

AGENDA







9/22/2008

47


SUPPLEMENTARY SPECIFICATIONS

� Apart from use-cases, there are other kind of

requirements

� Documentation

� Packaging

� Supportability� Supportability

� Licensing

� More of non-functional in nature for the scope of

the entire SuD

9/22/2008

48


REFERENCES

� Applying UML & Patterns, Craig Larman

� Text: Part II - Inception 6,7,8, 25

� Writing Effective Use-cases, Alistair Cockburn

� www.usecases.org for the Use-case Template

9/22/2008

49
