How to write use cases

Writing Requirements the Use-Case WayGloria StoilovaSenior Product Manager

What can go wrong in a product?

Rich in Features – yes, even too rich...

Poor in presentation – boring...

Interface Not intuitively designed – (developers do not have sense of design)

Usability issues – it’s all about the client, isn’t it?

Examples:

Appeal

Do not ever compromise at requirements stage

Be Aggressive in specifying User Requirements (we are not stating our requirements)

Always have the user in mind Don’t get tied down by technology

alone. Technology is changing fast.

Need for Change Increased competitionNew Technologies changing systemsuser should be thrilled and excited

and not just satisfiedPlan for on-line usage not off-line

usageThink differentlyDo things differently

Collecting User Requirements

1st - Identify users.

2nd - Identify their roles, responsibilities and needs.

3rd - Asking users is not enough - observing user in action only can give complete picture of what he needs.

4th - User - Task Analysis.

5th - Define Problem Statements.

Use Case Model Use-Case Model is a model of the

system’s intended functions (use cases) and its surroundings (Actors).

The same use-case model is used in requirements analysis, design and test.

The use case model’s primary purpose is to communicate the system’s functionality and behavior to the customer or end user.

THE Actor An actor represents anything that

interacts with the system.

Actors are not part of the system, they represent roles a user of the system can play.

An actor may actively interchange information with the system.

THE Actor

An actor may be a passive recipient of information.

An actor can represent a human, a machine or another system.

Finding Actors: useful questions

Who is interested in a certain requirement?

Where in the organization is the system used?

Who will supply the system with the information, use this information, remove this information?

Who will use this function?

Finding Actors: more useful questions

Does the system use an external resource?

What actors do the use cases need?

Does one actor play several different roles?

Do several actors play the same role?

Use Cases The use case model is a dialogue between

actors and the system.

The use case is initiated by an actor to invoke a certain functionality in the system.

The use case is a complete and meaningful flow of events.

Taken together, all use cases constitute all possible ways of using the system.

Finding Use Cases: Useful Questions

What are the tasks of the actor?

Will the actor create, store, change, remove or read information in the system?

What use case will create, store, change, remove, or read, this information?

Will the actor need to inform the system about sudden, external changes?

Finding Use Cases: Useful Questions

Does the actor need to be informed about certain occurrences in the system?

Does the system supply the business with the correct behavior?

What use cases will support and maintain the system?

Can all functional requirements be performed by the use cases?

Who Reads Use-Case Documentation?

Customers - approve what the system should do.

Users - gain system understanding.

System developers- document system behavior.

Reviewers - examine the flow of events.

Who Reads Use-Case Documentation?

System analysts (designer) - provide the basis for analysis and design.

System Tester - used as a base for test cases.

Project Leader - provide input to project planning.

Technical Writer - Basis for writing the user’s guide.

Example: Time Tracking System

User will create a task.

User will update the task status by entering the efforts spent against each task, for each date.

Actors are not identified.

Talks from system Perspective.

Example: Use Case Approach

Actors: Team Managers, Team Members, Department Heads.

Team Managers will use the system to assign a task to subordinate.

Use Case Model (Continued)

Team Member will view the task and update the task status by specifying the details of the task execution.

Department head will access the system to view projects status in his domain.

Summary and Suggestions

Always identify Actors.

Prepare Actor - Attributes, Profiles, Responsibilities…

Identify Goals of each Actor.

Arrive at Actor - Tasks, sub-tasks, KPIs,

Summary and Suggestions While specifying requirements use Actor

names.

Make used language “User Oriented” in all concept documents and requirements.

It is not necessary to use tools alone to document use-cases.

It is the language used that is going to make the difference.

Thank you for your attention!

Good Luck with your project….

[email protected]