Software Requirements Specification of the IUfAs UUIS -- a Team 1 COMP5541-W10 Project Approach

Unified University Inventory System (UUIS), is an inventory system created for the Imaginary University of Arctica (IUfA) to facilitate its inventory management, of all the faculties in one system. Team 1 elucidates the functions of the system and the characteristics of the users who have access to these functions. It shows the access restrictions to different functionalities of the system provided to users, who are the staff and students of the University. Team 1, also, emphasises on the necessary steps required to prevent the security of the system and its data.

💡 Research Summary

The paper presents a comprehensive Software Requirements Specification (SRS) for the Unified University Inventory System (UUIS), an integrated solution designed to manage the inventory of the fictional Imaginary University of Arctica (IUfA). The authors begin by outlining the problem space: existing departmental inventory tools are fragmented, leading to data duplication, inconsistent reporting, and inefficient resource utilization. UUIS is proposed as a single, web‑based platform that consolidates all asset information across faculties, labs, and administrative units, while providing role‑based access for staff and students.

The document follows a standard SRS structure, starting with stakeholder identification and role definition. Four primary user roles are defined: System Administrator, Department Manager, General Staff, and Student. Administrators possess full CRUD (Create, Read, Update, Delete) privileges over all data and system configuration. Department Managers can manage assets within their own department, approve inter‑department transfers, and generate department‑specific reports. General Staff are limited to asset registration, inventory adjustments, and viewing reports for assets they own. Students have read‑only access to inventory listings and can submit loan requests for eligible items. A detailed permission matrix maps each role to allowed operations, ensuring clear separation of duties and compliance with internal control policies.

Functional requirements are grouped into five major modules:

1. Asset Management – defines the data model for assets (unique identifier, category, manufacturer, purchase date, location, condition, quantity). It includes automatic numbering, duplicate detection, and validation rules.

2. Inventory Movement – supports intra‑university transfers, external loans, and disposals. The module enforces a multi‑step workflow (request, approval, execution, confirmation) and records a full audit trail for each movement.

3. Loan & Return – integrates with the student information system to enforce borrowing limits, calculate overdue fees, and send automated notifications via email and SMS. The system tracks loan status in real time and updates asset availability accordingly.

4. Reporting & Auditing – provides configurable reports (monthly/annual inventory changes, department utilization, compliance logs) exportable in PDF and Excel formats. All changes are logged with before‑and‑after values, timestamps, and user identifiers; logs are digitally signed to guarantee integrity.

5. User & Security Management – leverages LDAP for single sign‑on, implements role‑based access control (RBAC), enforces password complexity, and mandates periodic vulnerability scans. Communication is secured with HTTPS/TLS, and the system must meet an availability target of 99.5 % with a mean response time under two seconds for typical queries.

Non‑functional requirements address performance, scalability, maintainability, and internationalization. The architecture is a three‑tier design: a React.js front‑end, a Spring Boot back‑end exposing RESTful APIs, and a PostgreSQL database. Swagger is used for API documentation, and the system is designed to be containerizable (Docker) to facilitate future micro‑service migration. Accessibility follows WCAG 2.1 guidelines, and the UI supports both Korean and English languages.

Testing strategy is multi‑layered: unit tests (JUnit), integration tests (Spring Test), end‑to‑end UI tests (Selenium), load testing (JMeter) targeting 200 concurrent users, and security testing (OWASP ZAP). Continuous integration pipelines automate build, test, and deployment processes. User Acceptance Testing (UAT) will involve real staff and student participants executing scenario‑based scripts, with feedback loops feeding back into the backlog.

Project management adopts Agile Scrum with two‑week sprints, daily stand‑ups, sprint reviews, and retrospectives. The product backlog is prioritized based on stakeholder value, and risk mitigation plans address potential issues such as staffing shortages, scope creep, external system integration delays, and security threats.

In conclusion, the SRS provides a detailed blueprint that aligns functional capabilities with security and quality objectives, promising to streamline IUfA’s inventory operations, improve data consistency, and enhance user satisfaction. The authors also outline a roadmap for future extensions, including mobile app support and integration with the university’s financial ERP, ensuring the system remains adaptable throughout its lifecycle.