Suppose that you are required to document a university’s library system, particularly focusing on the

functionality at the back end. The scope the system’s back end is defined as follows:

• You should include all system functions and data, such as borrowing items, accessing both
physical and electronic items, renewing loans, viewing a borrower’s account (including overdue
items and fines), searching catalogues for various items, renewing loans, login, and asking a
librarian. Note that this list is not exhaustive.
• Some functionalities (such as booking rooms, accessing databases, borrowing books) are
provided by applications integrated with the library system. As such, you will need to show that
the functionality is captured, but that no structural data is retained in this system.
• Front-end content, such as ‘getting started in the library’, information pages (with static HTML
content), the ‘About’ section, reference guides, and general information, is out of scope, and
thus is not required to be included in your work.

Some specific functionality is not necessarily apparent from public or student views, but should be
included:

• An ITS officer uploads a list of lists of active borrowers each year. The list contains staff, student
and ‘others’. On this list:
a. staff have a staff ID, barcode, name, DOB, and department
b. students have a student ID, barcode, name, DOB and department
c. others have a borrower ID, name, DOB, address & license number
• The uploaded list is compared to existing borrowers by the system. If a person has left the
university, his/her account will be removed if they have no unpaid fines. Otherwise, their
borrower status is changed to inactive, and their record is retained. A new borrower account is
created for a new person on the list
• Librarians can also add borrowers. They create a borrower account with a name, DOB, and an
expiry date.
• If borrowers do not have a card with a barcode (such as those that are just created by the
librarian), their borrowing status is pending until they collect a library borrowing card from the
library.
• If a borrower is late in returning items, a fine occurs. When a borrower has a fine exceeding $25,
they can no longer renew or borrow any items until the fine is paid. Library fines must be paid in
person to a librarian, who will then mark the fine as paid in the system and issue a receipt.
• Librarians can view any record in the system – catalogue items, borrower records, etc. They can
search for a record or scan a barcode (of an item or borrower) to view the data.
• A borrower’s status can either active, inactive, pending, temporary, or suspended.
• Staff may request the library to place items used by their course on ‘reserve’ or ‘restricted
borrowing’. Staff may also submit past exam papers to the library.
• The head librarian generates reports based on item usage, borrowing rates, and library usage by
department type (staff and student).

1
You are required to play the role as a technical business analyst, analysing the library system and
creating diagrams as requested in the following tasks. Note you are not modelling a website using
storyboards, site-maps etc., but rather the back-end behavioral and structural needs of the system.

Task 1: Requirements Documentation (4 points)

Write a requirements document, in plain English, for the scenario “Pay Fine”. You may need to make
creative assumptions for assignment purposes, and assume that you have conducted requirements
elicitation with the client.

Your requirements will be assessed based on whether they:

• are verifiable, non-ambiguous, consistent, and complete

• form a set of rules, not only a series of operations / process descriptions
• relate to system requirements, not only business process

Hint: This is a potentially large task if you let your imagination run away with you. Try to keep your
requirements to the minimum – you will not be assessed on your creativity, but your ability to write a
requirements document!

Task 2: Use case diagram (4 points)

You should provide one use case diagram that includes all actors and use cases within scope. Your
diagram must include use cases named ‘Pay Fine’ and ‘Borrow Books’. Your diagram will be assessed
based on:

• Consistency with the scope including the specific functionality requested

• Appropriate use of actors, includes/extends, and generalization
• Appropriate use of UML notation

Task 3: Use case textual description (4 points)

Borrowing a book is the key function of this system. This functionality includes searching, borrowing and
returning book to the library. Develop a description of the use case using “Template – Use Case textual
description” as per Appendix.

Hint: This is a potentially large task if copious low-level data is included, so ensure you provide the
appropriate level of information. For example, in the flow of events a step may be “Log in” or “System
validation” instead of “insert student card with bar code facing up for scanning”.

Task 4: Activity diagram (4 points)

Create an activity diagram to show the activities that are involved in a student searching for a book, and
placing it on hold. Your diagram will be assessed based on:

• Appropriate identification and use of activities, decisions, branches, etc.

2
 • Appropriate use of UML notation
Task 5: Test Case Generation (4 points)
Design a set of test cases based on the functional requirements specified in Task 1. Your test cases are
aimed at checking various functions related to the scenario “Pay Fine”. Remember that a complete test
case should contain both test input and expected output along with a unique ID.

3
Appendix: Template for use case textual description
Use Case Name This must have an identical name as one of the use cases in the use case diagram.
Summary A short paragraph describing the process that is followed.
Participating Actors List the primary actor (the person who initiate the use case) and the secondary
actors (anyone else who is involved in the use case). These should be a job title,
not individual’s name.
Be careful to distinguish between data and actors – e.g. in a childcare system, a
child’s data may be used, but it does not make the child an actor.
Flow of Events A numbered sequence of steps taken to achieve the goal. It should be possible to
achieve this goal by only following these steps, without having to follow any of the
alternative paths.
This list may also refer to other use cases (representing the “includes” relationship
discussed earlier), or it may specify extension points (where other use cases can
take over).
Pre-conditions A condition that must be true before the use case can even start. Write as a
predicate; that is a statement that is either true or false. E.g., for Withdraw Cash a
precondition is “The person is a customer of the bank.”
A pre-condition is not something that is checked within a basic course of events
(e.g. “there is enough money in the account”) – it is a condition that must be true
BEFORE the basic course events are event commenced.
Post-Conditions The state of the system after the goal has been achieved. For example, if the
customer successfully withdraws cash, their bank balance should be lower by the
withdrawn amount.
There may be multiple postconditions if multiple outcomes are possible.
Quality Any conditions, particularly non-functional characteristics, that should be
Requirements absorbed/ maintained that is specified by either the business or an external entity.