Use Cases A Holistic Approach to Requirements Extraction.

Use Cases

A Holistic Approach to Requirements Extraction

2 Terrell Hull – Use Cases: A Holistic Approach to Requirements Extraction

Overview

• The challenge of requirements capture– Requirements defined– Requirements standards– The “Yes, but…” syndrome– Poor requirements are expensive– What makes requirements difficult

• The benefits of the use-case approach– Examining the system from the frame of reference of the user– Benefits for test planning– Benefits for project planning and estimation

• Key use-case attributes– Intent, description, pre-conditions, etc.– Post-conditions as use-case discriminators

• Holistic Requirements Extraction Process– Brainstorming, idea reduction, storyboarding, etc.– Facilitating use-case workshops

The Challenge of Requirements Capture

Let’s explore some of the special problems and challenges that make

requirements capture and project success difficult


What is a requirement?

• A requirement is defined as:– “A condition or capability to which the

system [being built] must conform”• Definition adopted by the OMG, Rational

Software, Inc., and IEEE


What is a requirement?

• A requirement can also be defined as:• A software capability needed by the user to

solve a problem or achieve an objective• A software capability that must be met or

possessed by a system or system component to satisfy a contract, specification, standard, or other formally imposed documentation

– Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1997, p. 79


Requirements Standards

• Requirements should be (IEEE 830 standard):– Correct– Unambiguous

• “if and only if it can be subject to only one interpretation” (IEEE 830-1993, § 4.3.2, 1994)

– Complete– Consistent– Ranked for importance and stability– Verifiable– Modifiable– Traceable– Understandable


The Rock

• Customer says “bring me a rock”– We deliver a rock

• Customer looks at it and says, “Yes, but, what I really wanted was a small blue rock.”– We deliver a small, blue rock


The Rock

• Customer says “actually, I want a spherical one…”– We deliver a spherical blue rock

• Ultimately, it becomes clear that the customer really wanted a blue cat’s eye marble.

• We shall refer to this as the “Yes, but…” syndrome


Standish Group, 1994

• In the US, we spend on average over $250 billion on IT projects per year– Approximately 170,000 projects

• Average for large companies: $2,322,000• Average for medium companies: $1,331,000• Average for small companies: $434,000


Standish Group, 1994

• 31% of these projects get cancelled before they are even completed– $81,000,000,000 wasted per year

• (adding in projects that were completed before they were cancelled)

• 52.7% of these projects were more than 189% over budget when delivered– $59,000,000,000 spent on budget overruns


Poor Requirement Result in Project Failure

• Studies from recent software projects show that:– The most significant contributors to project

failure relate to requirements• The Standish Group International, Inc.’s

CHAOS Reports from 1994 to 1997, Dennis, MA


Requirements Defects are Expensive

• Requirements defects represent more than 70% of rework costs

• Rework consumes about 30-50% of a project budget

• Lack of user input was listed as the most frequent problem


What Makes Requirements Difficult?

• Requirements:– Are not always

obvious and have many sources

– Are not always easy to express clearly in words

– Change– Can be time-

sensitive

• Requirements have unique properties or property values– For example, they

are neither equally important or equally easy to meet



• Requirements are related to one another and other deliverables of the process in a variety of ways

• The number of requirements can become unmanageable if uncontrolled

• There are many different types of requirements at various levels of detail

• There are many interested and responsible parties, which means requirements need to be managed by cross-functional groups of people



• “It is absurd to believe that the human mind can come up with a consistent and relevant list of thousands of requirements in the form ‘The system shall….’ What’s more, these requirements specifications [do] not readily transform into design and implementation specifications.”

Benefits of Use Cases

Let’s look at the potential benefits of the use-case approach



• Use Cases are:– Systematic– Intuitive– Assist in extracting and capturing functional

requirements– Are scenario-based– Focus on the value added to the user– Serve as a launch point for analysis, design, and

testing



• Use cases have the following advantages:– Easy to write– Written in the language of the user– Provide cohesive scenarios– Maps easily to design– Scenarios can be used almost directly as

test scripts


Industry-standard Approach

• Use Cases have been used to model complex systems for the last decade– Originally Published by Jacobson in 1992

• Functional specification of object-oriented systems

• The Unified Modeling Language and Unified Process have been accepted as the international standard by OMG– Largest standards organization in history

• over 900 companies make up the group


Use Cases

• Captures system functionality from the perspective of the value expected by the user

• Captured early in the development lifecycle• Purpose

– Specify the context of a system– Capture the requirements of a system– Validate a system’s architecture– Drive implementation and generate test cases

• Developed by analysts and subject matter experts (SME)


The Unified Process


Use Cases Drive Analysis and Design Efforts

• Specify system capabilities from user perspective

• Form basis for system construction

• Trace directly to system architecture

• Two primary artifacts– Actors– Use Cases

Use Case 1 Use Case 2

Use Case 3

Actor1 Actor2


From the Perspectiveand Vocabulary of the User

• Use case descriptions– Describe the basic

course– Are written from the

user’s perspective– Using the actor’s

vocabulary– Clearly define the

user’s intent


Users “Own” Use Case Descriptions

– Use cases form “contract” between users and developers

– Users can evaluate the system before construction begins

– To change system behavior users remodel the appropriate actor and the use case

– The system architecture will be controlled from what the users wish to do with the system

Own = Responsible ForOwn = Responsible For


Use Cases Provide a Key Source for Estimation

• As we begin to approach the system requirements using use cases, we gain incrementally more accurate views of– How long it will take to build each use case– How much each use case will cost– What the inherent risks are for each use case– How important each use case is to the business– In what order the use cases should be delivered,

based on the dependencies between the use cases



• Define Actors• Identify Primary Use

Cases• Cross-reference Use

Cases with Actors• Describe the Use Case

Model– Intent and black-box

description

• Add Secondary Use Cases

Define Actors

Cross-reference Use Cases with Actors

Describe the Use

Case ModelAdd Secondary

Use Cases

Identify Primary

Use Cases



• Package the Use Cases• Prioritize Use Cases for

Delivery• Identify Primary and

Secondary Scenarios• Detail Primary Scenario• Detail Secondary

Scenarios

Package Use Cases

Prioritize Use Casesfor Delivery

Identify Primaryand Secondary

ScenariosDetail PrimaryScenario

Detail SecondaryScenarios



• Realize the Use Cases using Object Interaction Diagrams

• Create GUI Prototype• Refine Use Cases

based on OIDs and Prototypes

• Refine the Use Cases based on Design

Sequence/Collaborati

on Diagrams

GUI Prototype

Refine Use CaseBased on OIDs and

GUI PrototypesRefine Use Case

Based on Design



• 1 Primary Use Case Count– Estimating Secondary

Use Case by Percentage

• 2 Adjusted Primary Use Case Count– Based on description

• 3 Use Case Count– Adding actuals for

secondary use cases

Define Actors

Identify Primary

Use CasesCross-reference Use Cases with Actors

Describe the Use

Case ModelAdd Secondary Use

Cases



• 4 Prioritized Use Cases

• 5 Scenario Count• 6 Primary Scenario

– Event Count

• 7 Complete Scenario – Event Count

Package Use Cases

Prioritize Use Casesfor Delivery

Identify Primaryand Secondary

ScenariosDetail PrimaryScenario

Detail SecondaryScenarios



• 8 Realized Use Cases– Object Count– Function Count

Sequence/Collaborati

on Diagrams

GUI Prototype

Refine Use CaseBased on OIDs and

GUI PrototypesRefine Use Case

Based on Design


Questions, Comments, and Discussion...

The Use Case Document

A detailed description of the elements contained in the

Use Case Document


Use Case Document

• Use Case – Intent– Description– Requirements

Mapping

– Special Requirements

– Pre-conditions– Post-conditions– Flow of events– Primary scenario– Secondary scenario– Use case business

rules (optional)


Use Case Document

• Use Case– Intent

• Mission Statement for the use case that helps define crisp conceptual boundaries around the use case

• Provides a means of differentiating between similar use cases, while supplying a basis for allocating requirements to one use case or another

• Must describe something of measurable value that the use case offers the actor

• Attempts to capture the compelling business need that clearly identifies the “measurable value”

• Has a strong relationship to the post-condition of the use case, in that both describe the goal of the use case.


Use Case Document

• Use Case– Intent (Cont.)

• Describes the business goal of the use case, while the post-condition describes the goal of the system in support of the business goal

– Description• A brief high-level description of what the use case does

from a black-box perspective, from the frame of reference of the user (actor)

• Identifies individual aspects of functionality with which the user is familiar

• Should be written in active voice (i.e., the system displays a message to the actor)


Use Case Document

• Use Case– Description (Cont.)

• Describes the basic course (primary scenario)• Written from the frame of reference of the user (actor)• Uses consistent terminology reflecting the vocabulary of the

customer, not “system language”• Describes testable system requirements

– Requirements Mapping [optional]• This section lists the respective requirement Ids for functional

requirements related to each requirement addressed by the use case

– Use this if the customer provides you with a set of requirements that you must reference

– “what” the system does


Use Case Document

• Use Case– Special Requirements

• Details special requirements as well as other types of considerations for the use case

– How fast, how much, how big, how many, and how the feature will be used (usability requirements)

– Details availability, accuracy, security, and performance (response time), archiving requirements, transactional volume, etc.

– Pre-conditions• The state of the System at the start of the use case

represented as a list of conditions that must be true prior to the use case


Use Case Document

• Use case– Post-conditions

• The state of the system at the end of the use case regardless of which scenario has ecxecuted (except for scenarios ending in FAIL)

• A list of conditions that must be true when the use case has completed its successful execution

• Represented the overall goal of the use case from a system perspective

• Describes the effect (goal) of the use case in terms of the altered system state (either transient or persistent) in the wake of the instantiation (execution) of the use case

• Every use case must have at least one post-condition


Use Case Document

• Use case– Post-conditions (Cont.)

• If a use case has more than one post-condition, and they are antagonistic, then it should be decomposed until multiple use cases

– Flow of Events• Numbered series of declarative statements listing the

steps of a use case• Collection of all scenarios that comprise the use case

– Primary scenario– Secondary scenario

» Alternate scenario» Exceptional scenario


Use Case Document

• Use case– Primary scenario

• There is only one Primary Scenario for each use case that represents the most important course of events providing the best understanding of the use case

• Detailed in table format with one column devoted to Event (Actor), one column devoted to Response (System), and one column devoted to Secondary Scenarios


Use Case Document

• Use case– Secondary scenario

• Variants on the Primary Scenario• Exception cases that need to be handled

– For exception scenarios, name the scenario after the condition that fired the scenario (I.e., Invalid Username, Illegal Action, etc.)

• Normally terminate with RETURN or FAIL• Rarely, if ever, terminate with END


Use Case Document

• Use case– Scenario terminators

• A terminator of END in a primary scenario means that the use case instance has completed successfully

– The post-condition has necessarily been met

• In a secondary scenario, END implies that execution control has been passed permanently to the secondary scenario

– Such as a shutdown request)


Use Case Document

• Use case– Scenario terminators (Cont.)

• A terminator of RETURN only applies to secondary scenarios

– Indicates that the scenario returns to the event or response immediately following the one from which it branched

» Unless followed by the specific Event or Response reference number, such as “RETURN to P-R4,” indicating that he scenario returns to the fourth system response in the Primary Scenario


Use Case Document

• Use case– Scenario Terminators (Cont.)

• A terminator of FAIL only applies to secondary scenarios

– FAIL indicates the abandonment of the use case» Necessarily means that the use case post-

condition has not been met


Use Case Document

• Use case– Use case business rules (optional)

• Must appear whenever business rules exist at the use case or scenario level

• Each business rule shall be assigned a number and a name, which together are used to reference the business rules whenever they appear within the use case and scenarios

– Use case package business rules (optional)• Business rules that apply globally to the use case package• Each business rule shall be assigned a number and a name,

which together are used to reference the business rules that appear in the use case package



A Holistic Approach to Requirements

Extraction

Applying requirements elicitation techniques to

extract and specify system requirements


Define the System

• Early in system definition, decisions are made on what constitutes a:– Requirement– Documentation format– Language formality– Degree of requirements– Request priority and estimated effort– Technical and management risks– Scope


Requirements Elicitation Techniques

• Interviewing and questionnaires

• Requirements workshops

• Brainstorming and idea reduction

• Storyboards

• Prototyping


Interviewing Techniques

• Context-free questions– Gause and Weinberg, 1989– The more experience we have, the more patterns

we have seen, the more opinions we begin to form• These hurt us in requirements elicitation!!

• Value-added context– Once we have listened carefully to the customer’s

answers to our context-free questions,• We can exploit the customers tendency to “yes, but” by:

– Adding some solution context– This may give the user new insights, and perhaps even a

different view of the problem


Elicitation Techniques

• Requirements Workshop– Provides a framework for applying several

elicitation techniques such as brainstorming etc.

– These techniques lead to better use-case definition


Brainstorming

• Rules for brainstorming are the following: – Start out by clearly stating the objective of

the brainstorming session– Generate as many ideas as possible– Let your imagination soar– Do not allow criticism or debate while you

are gathering information– Once information is gathered, collate ideas


Brainstorming

• Idea Reduction– Brainstorming primarily uses inductive logic– Idea Reduction primarily uses deductive logic– Once you have collected enough ideas, you may

want to consolidate your results through idea reduction

• Now is the time to solicit criticism and comments regarding the ideas that have been captured

• Consolidate redundant ideas• Remove ideas that don’t fit


Storyboarding

• Storyboarding means using a tool to illustrate (and sometimes animate) to the users (actors) how the system will fit into the organization, and indicate how the system will behave

• The facilitator shows an initial storyboard to the group, and the group provides comments– The storyboard then evolves in "real time" during

the workshop• A tool as simple as the whiteboard can be

used for storyboarding


Use Case Workshops Are an Effective Means of Discovery

• Determine overall goal• Get the right people

– business / technical– skilled & motivated

• Use a skilled facilitator– preferably neutral– able to manage conflict

• Keep to time constraints– 1 - 3 days optimal

• Get the right result– consensus is nice but may

not be what is needed


Existing Systems Provide Pre-defined Requirements

• Danger of being drawn into analyzing the old system instead of focusing on the new

• Need to extract business needs free from technical constraint

• Use workshops to ensure new requirements are complete


Tricks of the Trade

• Ask everyone if there is anything missing

• Volunteer some bad suggestions. This way, the team can correct you and explain the exact roles of the system

• Always accept all suggestions– You can always remove duplicates and

superfluous items later


Define Use Cases

• Identify use cases• Focus on concrete use cases, avoid includes

and extends• Involve the participants

– They will provide the system overview

• Get somebody to draw a system view– Make sure it is visible to everyone

• Allow the use cases to have long names• A number of use cases will appear to have

parts in common


Write a Brief Description

• Write brief description for each use case

• Every actor will be associated with at least one use case

• New use cases will appear

• Some use cases will disappear– Use of post-condition as discriminator may

be helpful here


Define the Flow of Events

• Structure the text first

• Work with the use cases one by one

• Write down the different actions in order

• Identify alternative steps

• Remember to write down all issues, together with any assumptions you need to make along the way


Capture Supplementary Specifications

• There will be several requirements on the system that will not be readily captured in use cases– They will form a basis for capturing the

Supplementary Specifications


Trace Requirements to Use Cases

• Discuss which requirements are traced to which use cases

• There are always a number of requirements that can't be connected to any use case: – They can be general requirements that can't be

connected to any use case and need to be included to the list of supplementary specifications

– They can be requirements that have been forgotten and require either new use cases or changes to the existing use cases


Prioritize Use Case

• Use the following guidelines:– Front-load the risk– Back-load the complexity– Deliver producers before consumers– Attempt to deliver features that are the

most important to the customer first• Yielding to the other rules


Increments Are Based On Use Cases

Increment 1Increment 1Increment 1Increment 1

Use Case #1This is just some crazy text to

fill in a gap. Don’t take itseriously, or else your sanity

is in danger.

This is just some crazy text tofill in a gap. Don’t take it

seriously, or else your sanityis in danger.



is in danger.



Increment 2Increment 2Increment 2Increment 2



is in danger.





is in danger.



Increment nIncrement nIncrement nIncrement n

Use Case #nThis is just some crazy text to


is in danger.



Use Case #nThis is just some crazy text to


is in danger.



An increment consists of one or more use cases or use case scenarios

An increment consists of one or more use cases or use case scenarios


Focus On Business Needs!

• Remember that the purpose of this stage is to understand user requirements

• Don’t get too drawn into technology issues

• Analysis is primarily about discovery as opposed to invention


Plan a Use Case to Deliver

• Discuss relative importance of each use case with the users– deliver highest risk or most important use cases first

• Examine complexity estimates for use cases– deliver most complex use cases last

• Understand implicit constraints on order of delivery– some use cases must logically be delivered before others

• Can build the complete delivery plan at once– be prepared to update it after each incremental delivery


Incremental Delivery Benefits the Business

• Rapid IS support can be generated for business processes

• 100% of 20 % of the system is more useful than 20% of the whole system


Delivering Use Cases Maintains Credibility

• Puts usable pieces of system in users hands quickly

• Users and managers are kept happy because they see early results

• Users “own” use cases


Summary

• The challenge of requirements capture– Requirements defined– Requirements standards– The “Yes, but…” syndrome– Poor requirements are expensive– What makes requirements difficult

• The benefits of the use-case approach– Examining the system from the frame of reference of the user– Benefits for test planning– Benefits for project planning and estimation

• Key use-case attributes– Intent, description, pre-conditions, etc.– Post-conditions as use-case discriminators

• Holistic Requirements Extraction Process– Brainstorming, idea reduction, storyboarding, etc.– Facilitating use-case workshops



Date post:	21-Dec-2015
Category:	Documents
View:	212 times
Download:	0 times

Use Cases A Holistic Approach to Requirements Extraction.

Documents