AstroLift Gym Management — BA Case Study

01Business Problem & Objectives

Gym teams commonly track members, renewals, attendance, payments, and workout plans in separate spreadsheets or messages. Staff repeat data entry, overdue memberships are hard to spot, trainers lack a shared view of member plans, and management cannot see reliable operational performance.

Objective 1: Create one source of truth for memberships, payments, workouts, and attendance.
Objective 2: Match system access to admin, trainer, and member responsibilities.
Objective 3: Reduce repetitive administration and make expiring or overdue memberships visible.
Objective 4: Give management timely KPIs for retention, revenue, and facility usage.

02As-Is vs To-Be Process

As-Is: Staff registers a member on paper or a spreadsheet → payment is recorded separately → attendance is marked manually → trainers share plans through messages → management combines records later for reporting.

To-Be: Admin creates a member profile and activates a plan → payment status updates the membership → attendance is recorded against the same account → trainer assigns and reviews workouts → role-based dashboards show current actions and KPIs.

03Functional Requirements

FR1: The system authenticates users and displays features according to admin, trainer, or member role.
FR2: Admins can create member records, assign plans, and manage activation, expiry, renewal, or suspension.
FR3: Staff can record payments and view outstanding or completed payment status.
FR4: Trainers can create and assign workout programmes and review member progress.
FR5: Staff can record attendance and retrieve attendance history by member and date.
FR6: Dashboards summarise active memberships, payment status, attendance, and workout activity.

04Non-Functional Requirements

Category	Requirement
Security	Server-side role checks prevent users from viewing or changing unauthorised records.
Performance	Member search and dashboard summaries return in under 2 seconds under normal load.
Reliability	Membership, payment, and attendance updates are transactional and do not create partial records.
Usability	Frequent front-desk tasks are completable in three primary actions or fewer.
Maintainability	Frontend, API, and business rules remain modular and testable.

05User Story & Acceptance Criteria

As a gym administrator, I want to renew a member's plan and record payment in one workflow, so that access and financial records remain consistent.

Given an existing member and a valid plan, when payment is confirmed, then the new membership dates and paid status are saved together.
Given payment fails or is cancelled, when the workflow ends, then the current membership remains unchanged.
Given a successful renewal, when the admin returns to the dashboard, then the member no longer appears in the expiring list.

06Use Case: Record Member Check-In

ActorFront-desk administrator

PreconditionThe member exists and the administrator is signed in.

Main flow1. Search for member. 2. System displays membership status. 3. Staff confirms check-in. 4. System creates a timestamped attendance record. 5. Dashboard totals update.

Alternate flowIf membership is expired or suspended, the system warns staff and does not silently grant access.