Scribd
Upload
36 views5 pages

Week4 Unit3 Notes KFL

A use case is a requirements analysis concept that describes how users interact with a system to achieve specific goals, detailing a sequence of events and user-system interactions. Actors represent user roles and system components involved in these interactions, while scenarios illustrate specific actions within use cases. Creating a use case diagram involves listing main system functions, defining relationships, and visually representing actors and their connections to the use cases.

Uploaded by

thembi malinga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
36 views5 pages

Week4 Unit3 Notes KFL

A use case is a requirements analysis concept that describes how users interact with a system to achieve specific goals, detailing a sequence of events and user-system interactions. Actors represent user roles and system components involved in these interactions, while scenarios illustrate specific actions within use cases. Creating a use case diagram involves listing main system functions, defining relationships, and visually representing actors and their connections to the use cases.

Uploaded by

thembi malinga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

What is a use case?

•A requirements analysis concept


•A case of a use of the system/product
•Describes the system's actions from the point of view of a user
•Tells a story
•A sequence of events involving
•Interactions of a user with the system
•Specifies one aspect of the behaviour of a system, without specifying the structure of the
system
•Is oriented toward satisfying a user's goal

Use Case Descriptions


•actors - something with a behaviour or role, e.g., a person, another system, organization.
•scenario - a specific sequence of actions and interactions between actors and the system,
a.k.a. a use case instance
•use case - a collection of related success and failure scenarios, describing actors using the

system to support a goal .

What is an Actor?
•Include all user roles that interact with the system
•Include system components only if they responsible for initiating/triggering a use case.
•For example, a timer that triggers sending of an e-mail reminder
•primary - a user whose goals are fulfilled by the system
•importance: define user goals
•supporting - provides a service (e.g., info) to the system
•importance: clarify external interfaces and protocols
•offstage - has an interest in the behaviour but is not primary or supporting, e.g.,
government
•importance: ensure all interests (even subtle) are identified and satisfied
Finding Actors [2] Ask the
following questions:
•Who are the system’s primary users?
•Who requires system support for daily tasks?
•Who are the system’s secondary users?
•What hardware does the system handle?
•Which other (if any) systems interact with the system in question?
•Do any entities interacting with the system perform multiple roles as actors?
•Which other entities (human or otherwise) might have an interest in the system's output?

Example Use-Case Diagram

Generalization
The child use case inherits the behaviour and meaning of the parent use case.
•The child may add to or override the behaviour of its parent.
Include
Include Example

Conclusion
How to create use case diagram
1. List main system functions (use cases) in a column:
–think of business events demanding system’s response
–users’ goals/needs to be accomplished via the system
–Create, Read, Update, Delete (CRUD) data tasks
–Naming use cases – user’s needs usually can be translated in data tasks

2. Draw ovals around the function labels


3. Draw system boundary
4. Draw actors and connect them with use cases (if more intuitive, this can be done as step
2)
5. Specify include and extend relationships between use cases (yes, at the end - not before,
as this may pull you into process thinking, which does not apply in UC diagramming).

You might also like