BISM7255

Business Information Systems Analysis and Design

Toy Library Assignment (Part 1)

Background

Unlimited  Quality   Play,   Learning  and  You   (UQPLAY)   is  a   not-for-profit  charitable organisation that runs a community-based Toy Library. The Toy Library lends educational and recreational toys to registered members—primarily families, carers, early childhood educators, and local community groups—with the aim of fostering development through play, supporting learning, and promoting inclusive access to quality toys.

UQPLAY’s current operations are entirely manual, relying on spreadsheets, paper records, and phone/email communication. This has become increasingly difficult to manage as the organisation grows and the number of customers, toys, and supplier relationships increases. UQPLAY has now commissioned your team to design a comprehensive information system that will be the foundation for a new digital application. The system must support day-to-day operations  and  reflect  the  real-life  complexities  of  running  a  toy  lending  service.  This assignment represents the analysis and design phase of that project.

Your role is to analyse, plan, and model how this application should function. To do this effectively, you will need to research how library systems, inventory-based lending models, and customer service platforms operate—especially in charitable or community-focused contexts. Your system design will need to support a range of activities in four areas:

1- Toy Lending and Inventory Management

UQPLAY lends a variety of toys, games, and activity kits, which must be categorised by age range; toy genre/theme (e.g. physical play, logic/puzzle, sensory play, imaginative play); loan duration limits (e.g. short-term vs long-term); flags for cleaning and hygiene checks after each loan before being made available again; and security deposit for high-value items and electronic toys.

There must be processes to check-in and out, return and overdue tracking, Log feedback from  parents  and  required  maintenance  (e.g.,  missing  pieces,  broken  parts).  The maintenance requires a maintenance logbook that documents repair actions taken by staff.

2- Lifecycle and Disposals

Every toy has a maximum usable life after which it should be either retired from lending, donated or sold in a community sale. Your system should be able to track how many times a toy has been borrowed and flag toys that are nearing end-of-life for review.

3- Customer Management

All users must register with the library to borrow items. Upon borrowing or returning, users can leave feedback or a condition report. The system should track members activities, borrowing history, security deposits, outstanding returns or fines. User feedback should be visible to others browsing items, creating a sense of trust and shared experience.

4- Supplier and Order Management

UQPLAY regularly sources toys, accessories, and replacement parts from a network of suppliers. To support procurement activities, the system must also: 1) maintain a supplier registry with  contact  information,  ordering  history,  and  product  types  offered;  2)  track purchase orders, including order date, Items requested, cost and delivery dates, payment status (Condition upon arrival (for quality checks)); 3) track internal restocking and item acquisition,  including  who  placed  the  order,  reason  for  acquisition  (new  purchase, replacement, etc.), and associated toys that require replacement parts. Where applicable, the system should be able to record correspondence or delivery issues related to suppliers.

Business Goal

The new system should bring UQPLAY into the digital age by:

•    Reducing administrative workload

•    Improving the toy borrowing experience

•    Ensuring better hygiene and safety for children

• Supporting better tracking of orders, toys, and customer activity

•    Providing insights into which toys are most used, most loved, or most problematic

Your Role

As a future business systems professionals, you are formally engaged as a consulting analysis and design group tasked with delivering a comprehensive, high-quality system proposal for UQPLAY’s new digital platform. You are expected to model the system as if it were being prepared for real-world implementation by a development team. You will be responsible for:

•    Investigating    and     understanding    the     operational,    customer-facing,     and administrative needs of UQPLAY.

•    Eliciting  and  documenting  functional  and   non-functional  system   requirements through a structured and analytical approach.

•    Designing a complete system solution using industry-standard UML techniques and tools.

•    Producing a rigorous, well-structured report that would be suitable for delivery to UQPLAY’s management and an external development agency.

Deliverables (Report)

Your group must produce a professionally formatted Executive Report that presents your system analysis and design for UQPLAY. This report should be clear, structured, and suitable for delivery to both academic assessors and UQPLAY’s management as if it were a real client submission. Your report must include the following core components:

1. Title Page: Including project title, students’ names and IDs

2. Executive  Summary  (½ to  1  page): A  summary  of  the  purpose,  scope,  and  key outcomes of your analysis and design. This should include key challenges identified, your  high-level  solution  approach,  and  a  brief  summary  of  deliverables  (e.g.  UML diagrams, identified requirements). The summary should be written for a non-technical stakeholder (e.g., UQPLAY’s board or executive team).

3.  Table of Contents: Add an autogenerated table of content with  major headings and subheadings.

4. Requirements  Specifications: Develop  a  comprehensive  set  of  requirements  that reflects  a  deep  understanding  of  UQPLAY’s  operational,  customer  service,  and administrative needs. These requirements must be expressed using the standard User Story  format  and  supported  by  detailed  Acceptance  Criteria  to  ensure  clarity  and testability. This section will form the foundation for your UML diagrams and system design work. The quality and completeness of your user stories will directly impact how well the system model meets UQPLAY’s expectations.

4.1. Functional Requirements: You must submit at least 10 functional requirements written as User Stories, each with a minimum of 6 Acceptance Criteria.

o Each functional User Story must follow this structure:

As a [type of user], I want to [perform. an action], so I can [achieve a goal].

o Examples of user types: Registered customer, Library staff etc

o Each story must also be accompanied by at least six Acceptance Criteria, written as short, testable conditions that define when the story can  be  considered “done.” . Acceptance Criteria Format (examples):

The system must allow the user to book a toy for a specific loan period.

Users cannot borrow more than 3 items at once.

o Topics that must be covered in the 10 functional stories include:

§ Searching/filtering toys by genre, age group, or availability

§ Booking a toy or game (including deposits for high-value items)

§ Returning a toy and leaving feedback

§ Submitting toy maintenance reports (customers and staff)

§ Tracking overdue returns and generating alerts

o Each functional story should be numbered (e.g., F1–F10) for easy reference in other sections of the report.

4.2. Non-Functional Requirements: you must also submit at least 5 non-functional requirements, each expressed as a User Story with 6 or more Acceptance Criteria.

o Non-Functional User Story Template:

As a system administrator, I want the system to be [attribute], so users have a [quality experience].

o These stories should address quality attributes, including:

§ Usability (e.g., simple navigation for digitally inexperienced users)

§ Performance (e.g., loading time, responsiveness)

§ Security (e.g., data protection, login handling)

§ Availability/reliability (e.g., uptime, handling failure cases)

§ Scalability or maintainability

o Each non-functional story must also include 6 specific acceptance criteria, such as:

§ System loads in under 2 seconds for 90% of requests.

§ Passwords are stored using industry-standard hashing algorithms.

o Non-functional  stories  should  be  numbered  (e.g.,  NF1–NF5)  and  clearly distinguished from the functional ones.

5. UML Diagrams

Provide an overview of your design methodology.

•   Justify key decisions in your system design (e.g. what data entities were created, why particular relationships were established, which processes were prioritised).

•   Show   how  your  design   meets   UQPLAY’s  functional   and   non-functional requirements.

•    Include brief descriptions to each of the UML diagrams that demonstrate your understanding of the case.

You need to create eight UML models based on the description of business requirements. Document any assumptions you made (if any) underneath each diagram. All UML models MUST be created with Enterprise Architect (EA), and each diagram must be exported as an image and pasted into your final report. This should include:

• 2 x Use Case Diagrams showing major actors and their interactions with the system.

o At least 2 actors

o At least 1 actor generalisations

o At least 20 use cases

o At least 5 <> relationships

o At least 5 <> relationships

• 2 x Activity Diagrams.  DO NOT model the Login or Registration process.

o Each diagram must include at least 15–20 activities

o At least 3 swimlanes

o At least 2 decision points

o Clear start and end states

o Use of fork/join or parallel flows where appropriate

• 2 x Sequence Diagrams showing system and actor messages for key workflows.

o Each diagram must include 3 – 4 lifelines

o At least 15 messages exchanged

o At least 1 example of Self messages

o Use of fragments such as alt, loop, or opt as needed

• 1 x State Diagram

o At least 10 distinct states

o Clear transitions between all states

o Use of triggers and actions for each transition

o Entry and/or exit actions where applicable

• 1 x Class Diagram

o At least 10 classes

o At least 3 aggregation or composition relationships

o At least 4 associations

o At least 2 generalisation relationships

o Each class must include at least 5 attributes with appropriate visibility and data types

o Use of multiplicity indicators (e.g., 1..*, 0..1)

Some suggestions of possible diagrams for the 2 Use Case, 2 Activity and 2 Sequence diagrams are:

•   A parent browses the catalogue, checks availability, reserves a toy for their child and receives a confirmation.

•    Maintenance staff receive a returned toy, inspects it, it is cleaned or repaired, and marked  ready  for  borrowing  or  prepared  for  retirement  (to  be  either  sold  or discarded) and a possible replacement is suggested for order.

NOTE: Students are welcome to detail other scenarios if they so wish.

6. Statement of AI Usage

This task has been designed to be challenging, authentic, and complex. Whilst students may use  AI  technologies,  successful  completion  of  assessment  in  this  course  will  require students to critically engage in specific contexts and tasks for which artificial intelligence will provide  only  limited  support  and  guidance. To  pass  this  assessment,  students  will  be required to demonstrate detailed comprehension of their written submissions independent of AI tools. If AI has been used it must be acknowledged.

•   Clearly  state  the  extent  to  which  AI  tools  were  used  (if  any)  during  the assignment.

•    Examples  may  include:  using  AI  to  generate  placeholder  text,  assist  with formatting, or brainstorm problem statements.

•    If no AI was used, a statement confirming that should be included.

Note: AI cannot be used to generate UML diagrams or requirements models. Any use in those areas will result in a mark of zero for the affected section.