Writing Requirements the Writing Requirements the Use-Case WayUse-Case Way

Sreeram Kishore ChavaliSreeram Kishore Chavali

What can go wrong in a What can go wrong in a product: examplesproduct: examples

Rich in FeaturesRich in Features Poor in presentationPoor in presentation Interface Not intuitively designedInterface Not intuitively designed Usability issuesUsability issues

AppealAppeal

Do not ever compromise at Do not ever compromise at requirements stagerequirements stage

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

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

alone. Technology is changing fast.alone. Technology is changing fast.

Need for ChangeNeed for Change

Increased competitionIncreased competition New Technologies changing systemsNew Technologies changing systems user should be thrilled and excited and user should be thrilled and excited and

not just satisfiednot just satisfied Plan for on-line usage not off-line Plan for on-line usage not off-line

usageusage Think differentlyThink differently Do things differentlyDo things differently

Collecting User Collecting User Requirements Requirements

Identify usersIdentify users Identify their roles, responsibilities Identify their roles, responsibilities

and needsand needs Asking users is not enough observing Asking users is not enough observing

user in action only can give complete user in action only can give complete picture of what he needs.picture of what he needs.

User - Task AnalysisUser - Task Analysis Define Problem StatementsDefine Problem Statements

Use Case ModelUse Case Model

Use-Case Model is a model of the Use-Case Model is a model of the system’s intended functions (use system’s intended functions (use cases) and its surroundings (Actors)cases) and its surroundings (Actors)

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

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

ActorActor

An actor represents anything that An actor represents anything that interacts with the systeminteracts with the system

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

An actor may actively interchange An actor may actively interchange information with the systeminformation with the system

An actor may be a passive recipient of An actor may be a passive recipient of informationinformation

ActorActor

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

Finding Actors: useful Finding Actors: useful questionsquestions

Who is interested in a certain Who is interested in a certain requirement?requirement?

where in the organization is the where in the organization is the system used?system used?

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

who will use this functionwho will use this function

Finding Actors: useful Finding Actors: useful questionsquestions

Does the system use an external Does the system use an external resource?resource?

What actors do the use cases What actors do the use cases need?need?

Does one actor play several Does one actor play several different roles? Do several actors different roles? Do several actors play the same role?play the same role?

Use CasesUse Cases

A use case model is a dialogue between A use case model is a dialogue between actors and the systemactors and the system

A use case is initiated by an actor to A use case is initiated by an actor to invoke a certain functionality in the invoke a certain functionality in the systemsystem

A use case is a complete and A use case is a complete and meaningful flow of eventsmeaningful flow of events

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

Finding Use Cases: Useful Finding Use Cases: Useful QuestionsQuestions

What are the tasks of the actor?What are the tasks of the actor? Will the actor create, store, change, Will the actor create, store, change,

remove or read information in the remove or read information in the system?system?

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

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

Finding Use Cases: Useful Finding Use Cases: Useful QuestionsQuestions

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

Does the system supply the business Does the system supply the business with the correct behavior?with the correct behavior?

What use cases will support and What use cases will support and maintain the system?maintain the system?

Can all functional requirements be Can all functional requirements be performed by the use cases?performed by the use cases?

Who Reads Use-Case Who Reads Use-Case Documentation?Documentation?

Customers - approve what the system Customers - approve what the system should doshould do

Users - gain system understandingUsers - gain system understanding system developers- document system system developers- document system

behaviorbehavior reviewers - examine the flow of eventsreviewers - examine the flow of events system analysts (designer) - provide system analysts (designer) - provide

the basis for analysis and designthe basis for analysis and design

Who Reads Use-Case Who Reads Use-Case Documentation?Documentation?

System Tester - used as a base for System Tester - used as a base for test casestest cases

Project Leader - provide input to Project Leader - provide input to project planningproject planning

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

Example:Time Tracking Example:Time Tracking SystemSystem

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

Actors are not identifiedActors are not identified Talks from system PerspectiveTalks from system Perspective

Example: Use Case Example: Use Case ApproachApproach

Actors:Team Managers, Team Actors:Team Managers, Team Members, Department HeadsMembers, Department Heads

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

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

Use Case Model (Contd..)Use Case Model (Contd..)

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

Summary and SuggestionsSummary and Suggestions

Always identify Actors Always identify Actors Prepare Actor - Attributes, Profiles, Prepare Actor - Attributes, Profiles,

ResponsibilitiesResponsibilities Identify Goals of each Actor Identify Goals of each Actor Arrive at Actor - Tasks, sub-tasksArrive at Actor - Tasks, sub-tasks While specifying requirements use Actor While specifying requirements use Actor

names names Make Language User Oriented in all Make Language User Oriented in all

concept documents and requirementsconcept documents and requirements

Summary and SuggestionsSummary and Suggestions

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

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