• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
How to write use cases

How to write use cases



A quick start How to write use cases.

A quick start How to write use cases.



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    How to write use cases How to write use cases Presentation Transcript

    • Writing Requirements the Use-Case Way Gloria Stoilova Senior 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 competition New Technologies changing systems user should be thrilled and excited and not just satisfied Plan for on-line usage not off-line usage Think differently Do 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…. gloria.stoilova@gmail.com