Writing Effective Use Cases By Alistair Cockburn

Writing Effective Use Cases Pdf

Download Free Writing Effective Use Cases By Alistair Cockburn Pdf

Introduction: Writing Effective Use Cases Pdf

Getting Started With Writing Effective Use Cases Pdf, A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system’s behavior under various conditions as it responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders.
Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios.
Use cases are fundamentally a text form, although they can be written using flow charts, sequence charts, Petri nets, or programming languages. Under normal circumstances, they serve to communicate from one person to another, often to people with no special training. The simple text is, therefore, usually the best choice.
The use case in Writing Effective Use Cases Pdf, as a form of writing, can be put into service to stimulate discussion within a team about an upcoming system. They might later use that the use case form to document the actual requirements. Another team might later document the final design with the same use case form.
They might do this for a system as large as an entire company, or as small as a piece of a software application program. What is interesting is that the same basic rules of writing apply to all these different situations, even though the people will write with different amounts of rigor, at different levels of technical detail.
When the use cases in Writing Effective Use Cases Pdf, document an organization’s business processes, the system under discussion is the organization itself. The stakeholders are the company shareholders, customers, vendors, and government regulatory agencies. The primary actors will include the company’s customers and perhaps their suppliers.
When the use cases record behavioral requirements for a piece of software, the system under discussion is the computer program. The stakeholders are the people who use the program, the company owning it, government regulatory agencies, and other computer programs. The primary actor will be the user sitting at the computer screen or another computer system.

Writing Effective Use Cases Chapters and Sections

Table of Contents For Writing Effective Use Cases Pdf

Chapter 1 Introduction to Use Cases

WHAT IS A USE CASE (MORE OR LESS)?

Use Case 1: Buy stocks over the web

Use Case 2: Get paid for car accident

Use Case 3: Register arrival of a box

1.2 YOUR USE CASE IS NOT MY USE CASE

Use Case 4: Buy something (Casual version)

Use Case 5: Buy Something (Fully dressed version)

Steve Adolph: “Discovering” Requirements in new Territory

1.3 REQUIREMENTS AND USE CASES

A Plausible Requirements File Outline

Use cases as a project linking structure

(Figure 1.: “Hub-and-spoke” model of requirements)

1.4 WHEN USE CASES ADD VALUE

MANAGE YOUR ENERGY

WARM UP WITH A USAGE NARRATIVE

Usage Narrative: Getting “Fast Cash”

PART 1 The Use Case Body Parts Chapter 2 The Use Case as a Contract for Behavior

2.1 INTERACTIONS BETWEEN ACTORS WITH GOALS

Actors have goals

(Figure 2.: An actor with a goal calls upon the responsibilities of another)

Goals can fail

Interactions are compound

A use case collects scenarios

(Figure 3.: Striped trousers: scenarios succeed or fail)

(Figure 4.: The striped trousers showing subgoals.)

2.2 CONTRACT BETWEEN STAKEHOLDERS WITH INTERESTS

(Figure 5.: The SuD serves the primary actor, protecting off-stage stakeholders)

2.3 THE GRAPHICAL MODEL

(Figure 6.: A stakeholder has interests)

(Figure 7.: Goal-oriented behavior made of responsibilities, goals and actions)

(Figure 8.: The use case as responsibility invocation)

(Figure 9.: Interactions are composite)

Chapter 3 Scope

A Sample In/Out List

3.1 FUNCTIONAL SCOPE

The Actor-Goal List

A Sample Actor-Goal List:

The Use Case Briefs

A sample of use case briefs

DESIGN SCOPE

(Figure 10.: Design scope can be any size)

Using graphical icons to highlight the design scope

Examples of design scope

Use Case 6: Add New Service (Enterprise)

Use Case 7: Add new Service (Acura)

(Figure 11.: System scope diagram for Acura – BSSO.)

Use Case 8: Enter and Update Requests (Joint System)

Use Case 9: Add new Service (into Acura)

Use Case 10: Note new Service request (in BSSO)

Use Case 11: Update Service request (in BSSO)

Use Case 12: Note updated Request (in Acura)

vii (Figure 12.: Use case diagrams for Acura – BSSO)

(Figure 13.: A combined use case diagram for Acura-BSSO.)

Use Case 13: Serialize access to a resource

Use Case 14: Apply a Lock Conversion Policy

Use Case 15: Apply Access Compatibility Policy

Use Case 16: Apply Access Selection Policy

Use Case 17: Make Service Client Wait for Resource Access

THE OUTERMOST USE CASES

USING THE SCOPE-DEFINING WORK PRODUCTS

Chapter 4 Stakeholders & Actors

STAKEHOLDERS

THE PRIMARY ACTOR OF A USE CASE

Why primary actors are unimportant (and important)

Characterizing the primary actors

A sample actor profile map:

SUPPORTING ACTORS

THE SYSTEM UNDER DISCUSSION, ITSELF

INTERNAL ACTORS AND WHITE-BOX USE CASES

Chapter 5 Three Named Goal Levels

(Figure 14.: The levels of use cases)

USER-GOALS (BLUE, SEA-LEVEL)

Two levels of blue

SUMMARY LEVEL (WHITE, CLOUD / KITE)

Use Case 18: Operate an Insurance Policy

The outermost use cases revisited

SUBFUNCTIONS (INDIGO/BLACK, UNDERWATER/CLAM)

Summarizing goal levels

USING GRAPHICAL ICONS TO HIGHLIGHT GOAL LEVELS

FINDING THE RIGHT GOAL LEVEL

Find the user’s goal

Merge steps, keep asking “why”

(Figure 15.: Ask “why” to shift levels)

A LONGER WRITING SAMPLE: “HANDLE A CLAIM” AT SEVERAL LEVELS

Use Case 19: Handle Claim (business)

Use Case 20: Evaluate Work Comp Claim

viii Use Case 21: Handle a Claim (systems)

Use Case 22: Register Loss

Use Case 23: Find a Whatever (problem statement)

Chapter 6 Preconditions, Triggers, Guarantees

6.1 PRECONDITIONS

6.2 MINIMAL GUARANTEES

6.3 SUCCESS GUARANTEE

6.4 TRIGGERS

Chapter 7 Scenarios and Steps

7.1 THE MAIN SUCCESS SCENARIO, SCENARIOS

Main success scenario as the simple case

Common surrounding structure

The scenario body

ACTION STEPS

Guidelines for an action step

Guideline 1: It uses simple grammar

Guideline 2: It shows clearly, “Who has the ball”

Guideline 3: It is written from a bird’s eye point of view

Guideline 4: It shows the process moving distinctly forward

Guideline 5: It shows the actor’s intent, not movements

Guideline 6: It contain a ’reasonable’ set of actions

(Figure 16.: A transaction has four parts)

Guideline 7: It doesn’t “check whether”, it “validates”

Guideline 8: It optionally mentions the timing

Guideline 9: Idiom: “User has System A kick System B”

Guideline 10: Idiom: “Do steps x-y until condition”

To number or not to number

Chapter 8 Extensions

THE EXTENSION CONDITIONS

Brainstorm all conceivable failures and alternative courses

Guideline 11: The condition says what was detected

Rationalize the extensions list

Roll up failures

8.2 EXTENSION HANDLING

Guideline 12: Condition handling is indented

Failures within failures

Creating a new use case from an extension

Chapter 9 Technology & Data Variations

(Figure 17.: Technology variations using specialization)

Chapter 10 Linking Use Cases

SUB USE CASES

EXTENSION USE CASES

(Figure 18.: UML diagram of extension use cases)

When to use extension use cases

Chapter 11 Use Case Formats

FORMATS TO CHOOSE FROM

Fully dressed form

Use Case 24: Fully Dressed Use Case Template

Casual form

Use Case 25: Actually Login (casual version)

One-column table

Two-column table

RUP style

Use Case 26: Register for Courses

If-statement style

OCCAM style

Diagram style

The UML use case diagram

FORCES AFFECTING USE CASE WRITING STYLES

STANDARDS FOR FIVE PROJECT TYPES

For requirements elicitation

Use Case 27: Elicitation Template – Oble a new biscum

For business process modeling

Use Case 28: Business Process Template – Symp a carstromming

For sizing the requirements

Use Case 29: Sizing Template: Burble the tramling

For a short, high-pressure project

Use Case 30: High-pressure template: Kree a ranfath

For detailed functional requirements

Use Case 31: Use Case Name: Nathorize a permion

CONCLUSION ABOUT FORMATS

PART 2 Frequently Asked Questions

Chapter 12 When are we done?

Chapter 13 Scaling up to Many Use Cases

Chapter 14 Two Special Use Cases

14.1 CRUD USE CASES

Use Case 32: Manage Reports

Use Case 33: Save Report

14.2 PARAMETERIZED USE CASES

Chapter 15 Business Process Modeling

Modeling versus designing

(Figure 19.: Core business black box)

(Figure 20.: New business design in white box)

(Figure 21.: New business design in white box (again))

(Figure 22.: New business process in black-box system use cases)

Linking business- and system use cases

Rusty Walters: Business Modeling and System Requirements

Chapter 16 The Missing Requirements

Precision in data requirements

Cross-linking from use cases to other requirements

(Figure 23.: Recap of Figure 1.“”Hub-and-spoke” model of requirements”)

Chapter 17 Use Cases in the Overall Process

USE CASES IN PROJECT ORGANIZATION

Organize by use case titles

(Figure 24.: Sample planning framework.)

Use cases cross releases

Deliver complete scenarios

USE CASES TO TASK OR FEATURE LISTS

Use Case 34: Capture Trade-in

Feature list for Capture Trade-in

USE CASES TO DESIGN

A special note to Object-Oriented Designers

USE CASES TO UI DESIGN

USE CASES TO TEST CASES

Use Case 35: Order goods, generate invoice (testing example)

Acceptance test cases

THE ACTUAL WRITING(Writing Effective Use Cases Pdf)

A branch-and-join process

required per use case

Collecting use cases from large groups

Andy Kraus: Collecting use cases from a large, diverse lay group

Chapter 18 Use Cases Briefs and extreme programming

Chapter 19 Mistakes Fixed

NO SYSTEM (Writing Effective Use Cases Pdf)

NO PRIMARY ACTOR

19.3 TOO MANY USER INTERFACE DETAILS

VERY LOW GOAL LEVELS

PURPOSE AND CONTENT NOT ALIGNED

ADVANCED EXAMPLE OF TOO MUCH UI

Use Case 36: Research a solution – Before

Use Case 37: Research possible solutions – After

Download Now

 

Note: If you have any question about Download Free Writing Effective Use Cases Pdf Then you can comment it.

Related Posts:


Be the first to comment

Leave a Reply

Your email address will not be published.


*