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