17spm_L04
Use Cases Example
Part Time Teachers
SPM 2017 © Ron Poet Lecture 4 1
Project Description
� We are developing software to manage the employment, training and
payment of part time teaching staff at a university or other such
educational or training establishment.
� Before the start of each term or semester, the class directors produce a
list of teaching requirements which we must try and fill. Our
SPM 2017 © Ron Poet Lecture 4 2
list of teaching requirements which we must try and fill. Our
administrator will then attempt to find suitable staff and organise
training for them.
Project Description (2)
� All teaching requests must be approved by the PTT Director, who will
also have the facilities to check the budget. Our system will allow
Course Directors to enter requests, and will store them for approval by
the PTT director. It is expected that informal discussions will take
place outside this system before formal requests are made via the
SPM 2017 © Ron Poet Lecture 4 3
place outside this system before formal requests are made via the
system. [ Added after considering the role of the PTT director and
budget use cases ].
� After teaching starts, we will receive claims forms, which we pass to
the finance department for payment.
Project Description (3)
� Sometimes teachers will not turn up, as detected by the course director.
We will make sure that they are not paid and that they are informed of
this. In other cases, teachers will request a replacement by a named
individual or inform someone of a pending absence. The recruiter may
well find a replacement. This process will take place outside our
SPM 2017 © Ron Poet Lecture 4 4
well find a replacement. This process will take place outside our
system, but the recruiter will enter any replacement or absence into the
system. [ Added after considering the absence use cases. ]
� The claims forms will be paper based, to conform with the current
finance department procedures. Our system will record the approval of
any payments and provide the facilities for checking if a payment is
due. Any irregularities in payment will be handled outside the system.
[ added after considering the payment use cases ].
Project Description (4)
� All teachers will be given an automatic warning that it is time to
submit their next claim. [ Added after considering any Timer based
use cases. ]
� The recruitment process takes place outside our system, we just
provide facilities for teachers and teaching duties to be entered. [
SPM 2017 © Ron Poet Lecture 4 5
provide facilities for teachers and teaching duties to be entered. [
added after considering the “Assign teacher to duty” use case ].
� The system will maintain a record of teacher skills and training. The
actual training will not be part of the system. [ added after the training
use cases ].
�
Project Description (5)
� The system will store two types of data, current data referring to
classes that are about to run or running, and historical data of past
classes and teachers. Historical data will be purged after 5 years. [
Added after considering the remove use cases. ]
� The system will maintain create, update and read permissions for all
SPM 2017 © Ron Poet Lecture 4 6
� The system will maintain create, update and read permissions for all
information stored. [ Added after considering use case details ].
Actors
� Course Director: A person who identifies a part time teaching need.
� Recruiter: Finds people to do the teaching.
� Teacher: Does the teaching
� Payer: Organises the payment.
SPM 2017 © Ron Poet Lecture 4 7
� Trainer: Trains the teachers.
� PTT Director: Co-ordinates PTT activities.
Use Cases
� Request Teachers
� OK Teaching Request
� Check Teaching Assignments, Vacancies and Payments
o [ This is a consolidation of a number of different check use cases
SPM 2017 © Ron Poet Lecture 4 8
o
that appeared early in the design process. ]
� Enter New Teacher
� Assign Teacher to Duty
� Cancel Assignment
� Inform of No Show
� Inform of Replacement
� Inform of Absence
Use Cases (2)
� Check Teacher Skills
� Update Teacher Training Record
� Approve Payment
� Check Budget
SPM 2017 © Ron Poet Lecture 4 9
� Enter Payment Rates
� Maintain Staff List
� Maintain History Information
� Add Deadline
� Deadline Approaching
Non Functional Requirements
� The user interface must be a GUI.
� The system must run on a number of different types of machine,
including PC and Linux.
� Different levels of security must be implemented for different users.
SPM 2017 © Ron Poet Lecture 4 10
o Administrator, class director, teacher.
� Must be available at all times.
Initial Plan
� The aim here is to prioritise activities.
� Risks
o HIGH: Secretarial staff may reject the interface.
o LOW: Other staff may reject the interface.
SPM 2017 © Ron Poet Lecture 4 11
o
o MEDIUM: Database may not always be available.
o MEDIUM: We may have missed undocumented procedures.
Use Cases
� Must Have
o OK Teaching Request
o Check Teaching Assignments, vacancies and payments
o Enter New Teacher
SPM 2017 © Ron Poet Lecture 4 12
o
o Assign Teacher to Duty
o Cancel Assignment
o Request Teachers
Use Cases (2)
� Should Have
o Inform of No Show
o Inform of Replacement
o Inform of Absence
SPM 2017 © Ron Poet Lecture 4 13
o
o Approve Payment
o Check Budget
o Enter Payment Rates
o Maintain Staff List
Use Cases (3)
� Could Have
o Check Teacher Skills
o Update Teacher Training Record
SPM 2017 © Ron Poet Lecture 4 14
� Would Like to Have
o Maintain History Information
o Add Deadline
o Deadline Approaching
Plan of Action
� We need a prototype to help us design the secretarial interface. They
will mainly be involved in processing payment sheets, and so the
prototype should implement the approve payment use case.
� A suitable prototyping tool would be Visual Basic or Python on a PC.
� We will implement all of the Must Have use cases in version 1 and
SPM 2017 © Ron Poet Lecture 4 15
� We will implement all of the Must Have use cases in version 1 and
Should Have cases in version 2.