Get Cheapest Assignment in Australia, UK, US, UAE, Canada and NZ Order Now

COS80022 Software Quality and Testing

0 Comments

Assignment 1 – Requirements & Modelling
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 providedby 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 thusis 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).

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 (10 points)
Write a requirements document, in plain English, for the scenarios “Pay Fine” and “Borrow Books”. 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 (6 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’, as documented in Task 1. 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 (8 points)
Borrowing books is the key function of this system. This functionally includes searching, borrowing and returning books 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 (6 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.
•Appropriate use of UML notation

Submission

This is an individual assignment, which totals 30 points, 30% of the whole assessment of this unit. You are required to complete all four tasks and compose your answers into one single document in .doc, .docx, or .pdf file. Every student should submit his/her own work by 23.59pm Sunday Week 6. The assignment should be submitted via the assessment submission system in Canvas which integrates with the Turnitin plagiarism checking service. You will be penalised 10% of the assessment’s worth for each calendar day the task is late, up to a maximum of 5 days. After 5 calendar days, a zero result will be recorded. Students with special circumstances (acute illness, loss or bereavement, hardship or trauma) may apply for an extension up to five days.

Appendix: Template for use case textual description
Name
This must have an identical name as one of the use cases in the use case diagram. (it is an expanded description of it)
Version
Identifier to distinguish between versions of one use case.
Goal
A one-sentence summary of the use cases existence.
Summary
A short paragraph describing the process that is followed.
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.
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.
Triggers
The event that causes the use case to active.
For Withdraw Cash the trigger is “The person enters their car and PIN and selects Withdraw Cash”
Basic course 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).
Alternative Paths
Another way to achieve the same goal. This is also where failure paths are considered (e.g. insufficient cash for a withdrawal).
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.
Business Rules
Any conditions, including non-functional characteristics, that should be absorbed/ maintained that is specified by either the business or an external entity.
E.g., a childcare system may only enrol children where they have immunized oreover a certain age.
Notes
As numerous as the section above are, there may be some extra information that you need to record. This section is the dumping ground for anything you think is relevant to the use case but does not fit into any other categories.
Do not go crazy here – do ensure it relates to this particular use case.

Leave a Reply

Your email address will not be published. Required fields are marked *