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

In the 52-page document, we describe our approach to the Software Requirements Specification of the IUfA’s UUIS prototype. This includes the overall system description, functional requirements, non-functional requirements, use cases, the corresponding data dictionary for all entities involved, mock user interface (UI) design, and the overall projected cost estimate. The design specification of UUIS can be found in arXiv:1005.0665.

💡 Research Summary

The paper presents a comprehensive Software Requirements Specification (SRS) for the prototype of the Integrated University User Information System (UUIS) at the International University of Applied Sciences (IUfA). Spanning 52 pages, the document follows a conventional SRS structure while incorporating the specific project management practices of Team 2. It begins with an overview that defines the system’s purpose: to consolidate user data (students, faculty, staff, administrators) and support core university functions such as course and laboratory reservation, asset tracking, and reporting. The stakeholder analysis identifies four primary user groups and outlines their distinct expectations.

The functional requirements section enumerates twelve major modules, each broken down into granular sub‑requirements. For instance, the “User Management” module covers registration, profile view/edit, role assignment/revocation, and password reset, while the “Reservation Management” module handles room booking, conflict detection, calendar integration, and notification delivery. Every functional item is accompanied by preconditions, inputs, outputs, success and failure scenarios, priority levels, and traceability identifiers.

Non‑functional requirements are articulated with quantitative targets. Performance goals stipulate an average response time under two seconds and support for up to 500 concurrent users. Security mandates include SSL/TLS encryption, role‑based access control (RBAC), multi‑factor authentication (MFA), and comprehensive audit logging. The authors advocate a micro‑services architecture deployed via Docker/Kubernetes to achieve scalability, and they specify horizontal partitioning for the database. Availability is set at a 99.5 % annual SLA with disaster‑recovery objectives of a four‑hour recovery time objective (RTO) and a fifteen‑minute recovery point objective (RPO). Additional non‑functional attributes—maintainability, portability, internationalization, and compliance with WCAG 2.1 AA for accessibility—are also defined with measurable criteria.

Use‑case modeling is provided through UML actor‑system diagrams and narrative scenarios. Each use case includes a basic flow, alternative/exception flows, pre‑ and post‑conditions, and business rules. The password‑reset use case, for example, employs a three‑step verification process (email token, security question, one‑time password) to enhance security.

The data dictionary section supplies an Entity‑Relationship diagram comprising 18 entities (User, Role, Course, Reservation, Asset, etc.). For every attribute, the specification lists data type, length, constraints, default values, and indexing strategy. The schema is normalized to the third normal form (3NF), with foreign‑key relationships and cascade rules explicitly documented. Data retention policies and backup procedures are also described.

User‑interface mockups are presented as wireframes for key screens: login, dashboard, profile management, reservation calendar, and asset administration. Consistent navigation elements, side menus, and adherence to accessibility standards (color contrast, keyboard navigation, ARIA labels) are emphasized.

Cost estimation is performed using a bottom‑up approach. Personnel expenses (four developers, two QA engineers, one project manager), cloud infrastructure (compute instances, database licenses), tooling, testing, and deployment costs are aggregated on an annual basis. A risk buffer of 15 % is added to account for potential staff turnover, technical debt, and schedule slippage, resulting in a total projected budget of approximately USD 85,000.

The appendix includes a requirements‑traceability matrix linking each SRS item to design, implementation, and test artifacts, as well as a change‑control process that outlines impact analysis and approval workflow for any modifications. Overall, the document offers a thorough, well‑structured SRS that serves as a solid reference for university‑scale information systems. However, some non‑functional targets—particularly the ambitious performance and availability figures—may prove optimistic in a real‑world deployment and could require adjustment during the implementation phase.