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 ...
Appeal
 Do not ever compromise at requirements
stage
 Be Aggressive in specifying User
Requirements (we are not stating ...
Need for Change
Increased competition
New Technologies changing systems
user should be thrilled and excited
and not jus...
Collecting User Requirements
1st
- Identify users.
2nd
- Identify their roles, responsibilities and needs.
3rd
- Asking us...
Use Case Model
 Use-Case Model is a model of the system’s
intended functions (use cases) and its
surroundings (Actors).
...
THE Actor
 An actor represents anything that
interacts with the system.
 Actors are not part of the system, they
represe...
THE Actor
 An actor may be a passive recipient of
information.
 An actor can represent a human, a machine
or another sys...
Finding Actors: useful questions
 Who is interested in a certain requirement?
 Where in the organization is the system
u...
Finding Actors: more useful questions
 Does the system use an external resource?
 What actors do the use cases need?
 D...
Use Cases
 The use case model is a dialogue between
actors and the system.
 The use case is initiated by an actor to inv...
Finding Use Cases: Useful Questions
 What are the tasks of the actor?
 Will the actor create, store, change,
remove or r...
Finding Use Cases: Useful Questions
 Does the actor need to be informed about
certain occurrences in the system?
 Does t...
Who Reads Use-Case Documentation?
 Customers - approve what the system
should do.
 Users - gain system understanding.
 ...
Who Reads Use-Case Documentation?
 System analysts (designer) - provide the basis
for analysis and design.
 System Teste...
Example: Time Tracking System
 User will create a task.
 User will update the task status by entering
the efforts spent ...
Example: Use Case Approach
 Actors: Team Managers,
Team Members,
Department Heads.
 Team Managers will use the system to...
Use Case Model (Continued)
 Team Member will view the task and update the
task status by specifying the details of the ta...
Summary and Suggestions
 Always identify Actors.
 Prepare Actor - Attributes, Profiles,
Responsibilities…
 Identify Goa...
Summary and Suggestions
 While specifying requirements use Actor
names.
 Make used language “User Oriented” in all
conce...
Thank you for
your attention!
Good Luck with your project….
gloria.stoilova@gmail.com
Upcoming SlideShare
Loading in …5
×

How to write use cases

1,486 views

Published on

A quick start How to write use cases.

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,486
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
39
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

How to write use cases

  1. 1. Writing Requirements the Use-Case Way Gloria Stoilova Senior Product Manager
  2. 2. 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:
  3. 3. 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.
  4. 4. 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
  5. 5. 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.
  6. 6. 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.
  7. 7. 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.
  8. 8. THE Actor  An actor may be a passive recipient of information.  An actor can represent a human, a machine or another system.
  9. 9. 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?
  10. 10. 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?
  11. 11. 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.
  12. 12. 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?
  13. 13. 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?
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. Example: Use Case Approach  Actors: Team Managers, Team Members, Department Heads.  Team Managers will use the system to assign a task to subordinate.
  18. 18. 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.
  19. 19. Summary and Suggestions  Always identify Actors.  Prepare Actor - Attributes, Profiles, Responsibilities…  Identify Goals of each Actor.  Arrive at Actor - Tasks, sub-tasks, KPIs,
  20. 20. 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.
  21. 21. Thank you for your attention! Good Luck with your project…. gloria.stoilova@gmail.com

×