CSSE3002 Lecture Notes - Lecture 6: Lecture Recording, Flowchart, Blackboard
28 Jun 2018
School
Department
Course
Professor
Use Case Modelling Process
Another approach to capture and describe the requirements
Need to know:
1) who uses the system?
2) What do they need to do?
3) create use case diagram to give overall view of the system
4) simplify the diagram (splitting the diagram into smaller parts as segments of
systems)
5) pick a use case and expand, elaborate the use case with details
6) find problems, find missing parts of the use case and the system, or which one
sound similar and merge them
6) restructure use cases: make them more modular
7) user interface design(obtained details hence able to start designing) (how they
interact with system, do prototyping to clarify requirements)
Task 1: Identify Actors
-Whos gonna use the system? (primary human actors: simple and obvious)
-Then able to break it down(categories: hospital staff- nurse, doctor etc)
-Each type of actor has different requirements for the system
-Actors: talk to system (interact with the system: to do this, have to interact with this)
-Brownfield development: don’t assume users are actors, also look at ways to
improving, to improve the previous system, hence introduce new actors
Actor description template
-Description: a little bit of info for the actor (contextual information)
-Aliases: roles can be called different ways in different organisations, list all the
aliases (bank customer, bank client etc)
-Inherits: which actor’s behaviour it is from
-Protocol: reference to the API (to the protocol document)
-Real system: contact - client representative for questions and enquiries, requests
External systems as actors
-Stick figure: icon for an actor (for people)
-Boxes: for external system
Importance of actors
-Build system based on the requirements around the actors
-If not, might miss requirements (need to know what client needs and wants)
find more resources at oneclass.com
find more resources at oneclass.com
-Need to think about the type of person this actor represents
-Actors can represent abstract roles
-A user can play multiple roles, could be confusing
Identify Initial Use Cases
-What does it need to do (for every actors)?
-What do they want to achieve? Turn them into use cases
-Describe the activities in verb phase (e.g. withdraw money)
-Elicitation techniques: do interviews, survey etc to know what is required
Source of Use Cases
-From actual ppl that uses the system
-From the business analysts who interacts with ppl who use the system
-Different ppl have diff perspective of what needs to be done
-Domain material: look what similar systems do, determine what your system should
do
-Focus on what needs to be accomplished, instead of how it needs to be
accomplished
Identifying Use Cases
-Main tasks: what you need do?
-What do you need access to? What do you need to change? (standard details:
create, update, delete etc)
-Tell something to the system
-What feedback do u want from the system (alerts, messages etc)
Appropriate Size
-How big is the use case? Not big, not small - A use case is a transaction of events
that yield a useful result for an actor
-A use case: Give useful results, not too big and complex, not too detail
-Describe as verb phrase
-what actor does, in one place and one time (not over a period of time)
Use Case Diagram
-big overview in the entire system
-primarily to communicate ideas
Mis-use cases
find more resources at oneclass.com
find more resources at oneclass.com
Document Summary
Another approach to capture and describe the requirements. Whos gonna use the system? (primary human actors: simple and obvious) Then able to break it down(categories: hospital staff- nurse, doctor etc) Each type of actor has different requirements for the system. Actors: talk to system (interact with the system: to do this, have to interact with this) Brownfield development: don"t assume users are actors, also look at ways to improving, to improve the previous system, hence introduce new actors. Description: a little bit of info for the actor (contextual information) Aliases: roles can be called different ways in different organisations, list all the aliases (bank customer, bank client etc) Protocol: reference to the api (to the protocol document) Real system: contact - client representative for questions and enquiries, requests. Stick figure: icon for an actor (for people) Build system based on the requirements around the actors. If not, might miss requirements (need to know what client needs and wants)
