1) The document discusses writing requirements using a use-case model approach. It emphasizes identifying system actors and their goals, as well as use cases that represent meaningful interactions between actors and the system. 2) Key aspects of developing a use-case model are identifying relevant actors, their roles and responsibilities, then analyzing tasks and goals to derive use cases. Actors can represent both human and non-human entities. 3) Use cases should be written from the perspective of actors to ensure requirements capture intended system functionality and meet user needs. The use-case model provides documentation for various stakeholders throughout the software development lifecycle.

1. Writing
Requirements
the Use-Case
Way
Gloria Stoilova
Senior Product Manager

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. 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. 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. 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. 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. 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. THE Actor
 An actor may be a passive recipient of
information.
 An actor can represent a human, a machine
or another system.

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. 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. 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. 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. 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. 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. 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. 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. Example: Use Case Approach
 Actors: Team Managers,
Team Members,
Department Heads.
 Team Managers will use the system to assign a task
to subordinate.

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. Summary and Suggestions
 Always identify Actors.
 Prepare Actor - Attributes, Profiles,
Responsibilities…
 Identify Goals of each Actor.
 Arrive at Actor - Tasks, sub-tasks, KPIs,

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. Thank you for
your attention!
Good Luck with your project….
gloria.stoilova@gmail.com