Software Requirements Specification (SRS)

Old Laboratorians' Association (OLsA) Website

Version: 1.2
Date: 2026-04-02
Prepared for: OLsA Web Platform
Application Type: Laravel-based Web Application (Public Portal + Member + Admin + System Admin)

1. Introduction

1.1 Purpose

This document defines the functional and non-functional requirements for the OLsA website. It is intended to guide product ownership, development, QA, deployment, and operations teams.

1.2 Scope

The OLsA website is an alumni-focused digital platform supporting:

• public information and engagement,
• alumni/member lifecycle and approvals,
• events and registration with payment,
• virtual/hybrid event configuration with ticket tiers and additional fee components,
• donations and fundraiser campaigns,
• mentorship matching and feedback,
• resume bank access for approved stakeholders,
• blog and notices,
• operational communications (mail logs and templates),
• role-based administration,
• system administration and operational monitoring.

1.3 Definitions and Acronyms

• OLsA: Old Laboratorians' Association.
• RBAC: Role-Based Access Control.
• SRS: Software Requirements Specification.
• System Admin: privileged admin role with system-level operations.
• Payment Gateway: Stripe, SSLCommerz, bKash, eKpay integrations.

1.4 Product Perspective

This system is a monolithic Laravel application with modular features under public routes and authenticated/admin route groups. It uses role-permission middleware (role_permission:*) for authorization.

2. Overall Description

2.1 User Classes and Roles

1. Guest/Public User
   • View landing content, events, blog, policies, notice board, fundraisers.
   • Submit alumni registration and donation forms.
2. Authenticated User
   • Manage personal profile.
   • Manage own blog posts.
   • Access membership enrollment/payment flow.
3. Admin (Role-based)
   • Manage alumni, members, users, events, blog, notices, donations, fundraisers, payments, settings.
4. Batch Representative
   • Can review/approve alumni applications for relevant scope.
5. System Admin
   • Access /admin/system/* dashboard, user/role views, logs, status.

2.2 Operating Environment

• Backend: PHP 8.x + Laravel
• Database: MySQL
• Frontend: Blade templates + AdminLTE + custom CSS/JS
• Server: Apache/XAMPP-compatible deployment

2.3 Constraints

• Legacy and evolving schema support in some modules.
• Multiple payment gateways with different callback patterns.
• Role and permission matrix must remain consistent with middleware checks.

2.4 Assumptions and Dependencies

• Valid SMTP/mail transport configuration for notifications.
• Correct storage linkage (public/storage) for media.
• Payment credentials configured via admin settings/DB settings.

3. System Features and Functional Requirements

3.1 Authentication and Account Management

Description: Supports register/login, email verification, social login.

Requirements:

• FR-AUTH-001: The system shall allow user registration with name, email, and password.
• FR-AUTH-002: The system shall require email verification for verified-only routes.
• FR-AUTH-003: The system shall support Facebook login redirect and callback.
• FR-AUTH-004: The system shall enforce authenticated access for profile and membership routes.

3.2 Profile and Social Data

• FR-PROF-001: The system shall allow users to view and edit profile data.
• FR-PROF-002: The system shall support profile picture upload.
• FR-PROF-003: The system shall support LinkedIn connect, callback, sync, and disconnect.
• FR-PROF-004: The system shall support viewing member profile by batchcode route.

3.3 Alumni Registration and Approvals

• FR-ALM-001: The system shall provide public alumni registration create/store flows.
• FR-ALM-002: Admin shall view and manage alumni records.
• FR-ALM-003: Authorized reviewers shall approve/reject pending alumni applications.
• FR-ALM-004: Alumni search/filter shall be available by name, email, phone, batch, and identifiers.

3.4 Membership Enrollment and Payment

• FR-MEM-001: Verified authenticated users shall access membership landing.
• FR-MEM-002: Membership payment shall support member type and discount code inputs.
• FR-MEM-003: Admin shall configure membership amounts and discount code issuance.
• FR-MEM-004: Membership activation shall support payment verification workflow.

3.5 Event Management and Participation

Public

• FR-EVT-001: The system shall list active events and event detail pages.
• FR-EVT-002: The system shall allow member lookup during registration.
• FR-EVT-003: The system shall allow event registration and coupon validation.

Admin

• FR-EVT-004: Admin shall create/edit/delete events.
• FR-EVT-005: Admin shall upload and delete event photos.
• FR-EVT-006: Admin shall update registration payment status and references.
• FR-EVT-007: Admin shall manage event categories and event-category assignments.
• FR-EVT-008: Admin shall manage event coupons (create/edit/delete/list).
• FR-EVT-009: Admin shall configure virtual-event fields (virtual flag and meeting details) when applicable.
• FR-EVT-010: The system shall support ticket tiers and additional fee line items in event registration pricing.

3.6 Event Check-In

• FR-CHK-001: The system shall support member check-in endpoint for authenticated users.
• FR-CHK-002: Admin shall have check-in page with manual check-in capability.
• FR-CHK-003: Admin shall view check-in stats for each event.
• FR-CHK-004: Check-in shall validate eligibility/payment state as implemented by controller logic.

3.7 Payment Processing

• FR-PAY-001: The system shall initiate payment for event registrations.
• FR-PAY-002: The system shall process success/fail/cancel callbacks per provider route.
• FR-PAY-003: Admin shall configure Stripe, SSLCommerz, bKash, and eKpay settings.
• FR-PAY-004: eKpay integration shall support request signature generation and response verification.

3.8 Donations

• FR-DON-001: Public users shall submit donations with donor/member search support.
• FR-DON-002: Donation flow shall support callbacks for Stripe, SSLCommerz, and bKash.
• FR-DON-003: Admin shall filter, review, and update donation records.
• FR-DON-004: Admin shall view date-range donation reports.
• FR-DON-005: Admin shall export donation data to CSV.

3.9 Fundraisers

• FR-FND-001: Public users shall browse active fundraisers and detail pages.
• FR-FND-002: Admin shall CRUD fundraiser campaigns.
• FR-FND-003: Admin shall configure fundraiser module and display settings.

3.10 Blog and Content Publishing

• FR-BLG-001: Public users shall browse published blog posts.
• FR-BLG-002: Authenticated users shall manage own blog posts.
• FR-BLG-003: Admin shall manage blog posts and categories.
• FR-BLG-004: Blog shall support categories, tags, publishing state, and featured images.

3.11 Mentorship Program

• FR-MTR-001: Authenticated users shall create and maintain mentorship profiles.
• FR-MTR-002: Eligible users shall request mentor/mentee connections from suggested profiles.
• FR-MTR-003: Participants shall log mentorship sessions and mark mentorship cycles completed.
• FR-MTR-004: Participants shall submit post-cycle feedback and ratings.
• FR-MTR-005: Admin shall oversee mentorship pairings and status transitions.

3.12 Resume Bank and Talent Access

• FR-RSM-001: Active members shall upload and manage their resume profiles.
• FR-RSM-002: Approved corporate partners and eligible members shall browse approved resumes.
• FR-RSM-003: Resume views/downloads shall track engagement metrics.
• FR-RSM-004: Admin shall moderate resume visibility and status.

3.13 Job and Corporate Partner Module

• FR-JOB-001: Public users shall browse approved job posts and detail pages.
• FR-JOB-002: Authenticated users shall manage own job posts.
• FR-JOB-003: Admin shall moderate job posts and corporate partner approvals.
• FR-JOB-004: Public users shall be able to open a job application flow from job detail/apply routes.

3.14 Notices and Policies

• FR-NOT-001: Public users shall view notice board entries.
• FR-NOT-002: Admin shall manage notices including pinning and attachments.
• FR-POL-001: Public users shall view privacy policy and terms.
• FR-POL-002: Admin shall edit front-page policy content.

3.15 Front Page and Branding Settings

• FR-FP-001: Admin shall configure hero/topbar/footer content.
• FR-FP-002: Admin shall configure leader messages and photos.
• FR-FP-003: The system shall serve configured branding assets and leader images through dedicated media routes.

3.16 Role, Permission, and User Management

• FR-RBAC-001: The system shall enforce route permissions via role-permission middleware.
• FR-RBAC-002: Admin shall manage roles and role authorization matrix.
• FR-RBAC-003: Admin shall manage users (including role assignment).

3.17 Backup and Restore

• FR-BKP-001: Authorized admin users shall create database backup snapshots.
• FR-BKP-002: Authorized admin users shall upload, download, delete, and restore backup files.
• FR-BKP-003: Backup metadata shall include creation and table/row statistics.

3.18 Operational Communications and Mail Audit

• FR-MAIL-001: Admin shall manage configurable email templates for key system notifications.
• FR-MAIL-002: Authorized users shall review mail logs with filter/search/export capabilities.
• FR-MAIL-003: Admin shall preview templates, trigger test-send, and reset system templates to default content.

3.19 System Admin Module

• FR-SYS-001: System admin shall access dedicated dashboard under /admin/system.
• FR-SYS-002: System admin shall view users, roles, permission matrix, logs, and system status.
• FR-SYS-003: System status shall show DB connectivity, memory/disk indicators, and uptime data (as available).

4. External Interface Requirements

4.1 User Interface

• Responsive Blade views with AdminLTE for admin areas.
• Public pages use themed layouts with custom styling.
• Forms include validation error feedback and alert messaging.

4.2 Software Interfaces

• MySQL database via Eloquent ORM.
• Payment provider APIs via controller/service integrations.
• Social OAuth providers (Facebook and LinkedIn).

4.3 Communication Interfaces

• HTTP/HTTPS web routes.
• Callback endpoints for external payment providers.

5. Data Requirements

5.1 Core Entities

• users, roles, role_permissions
• alumni, members, addresses
• events, event_registrations, event_payments, event_coupons, event_categories, event_checkins, event_ticket_tiers, event_additional_fees, event_registration_fees
• donations, fundraisers, transactions
• jobs, corporate_partners, resume_profiles
• mentorship_profiles, mentorship_matches, mentorship_sessions, mentorship_feedback
• posts, categories, tags, post_tag
• notices, policies, settings, mail_logs, email_templates

5.2 Data Integrity and Validation

• Unique slugs for content entities where applicable.
• Foreign key constraints on major relationships.
• Validation rules at controller level for create/update requests.

6. Non-Functional Requirements

6.1 Security

• NFR-SEC-001: Authenticated/verified route protection for private features.
• NFR-SEC-002: Role-permission authorization checks for admin operations.
• NFR-SEC-003: Sensitive gateway credentials shall be stored in settings/env and not exposed publicly.
• NFR-SEC-004: CSRF protection shall be enforced for form submissions.

6.2 Performance

• NFR-PERF-001: Paginated listing for large datasets (users, alumni, posts, donations, etc.).
• NFR-PERF-002: Indexed lookup fields should be used for common search/filter keys.

6.3 Reliability and Availability

• NFR-REL-001: Backup and restore functionality shall support operational recovery.
• NFR-REL-002: Payment callback handling shall update transaction state consistently.

6.4 Maintainability

• NFR-MNT-001: Feature modules shall remain controller-model-view structured.
• NFR-MNT-002: Configuration values shall be centrally managed via settings where applicable.

6.5 Usability

• NFR-USE-001: Public and admin interfaces shall provide clear feedback for successful and failed actions.
• NFR-USE-002: Search and filter controls shall be provided for key management views.

7. Access Control Matrix (High Level)

8. Risks and Recommendations

1. Schema Drift Risk: Some modules evolved quickly; maintain migration discipline and environment parity.
2. Payment Callback Risk: Ensure idempotency and signature verification for all gateways.
3. Operational Risk: Ensure periodic backup validation (restore test in staging).
4. Authorization Risk: Keep role-permission matrix aligned with newly added routes.

9. Acceptance Criteria (System-Level)

• AC-001: All public routes render and behave according to intended feature scope.
• AC-002: Auth + verified flow gates private features correctly.
• AC-003: Admin routes enforce role_permission middleware constraints.
• AC-004: Event registration, payment callback, and check-in workflows execute end-to-end.
• AC-005: Donation and fundraiser modules support create/view/report/export operations.
• AC-006: Mentorship and resume-bank workflows enforce eligibility and role constraints.
• AC-007: Blog and notice content is publishable and visible on public pages.
• AC-008: System admin dashboard and subordinate routes are accessible to authorized users only.

10. Future Enhancements (Backlog Candidates)

• Audit trail standardization across all admin write actions.
• Advanced analytics dashboards (engagement, donation, campaign, conversion).
• Notification center (email/SMS/push) for lifecycle events.
• API-first layer for mobile integration.
• Enhanced observability (structured logs, health checks, alerts).

11. Traceability Overview

Primary implementation evidence was mapped from:

• routes/web.php route groups and middleware,
• controllers in app/Http/Controllers and app/Http/Controllers/Admin,
• models in app/Models,
• feature docs (FEATURES_DOCUMENTATION.md, docs/EVENT_CHECKIN.md, payment/linkedin guides),
• corresponding Blade views for public/admin surfaces.

This SRS is aligned with the current codebase behavior as of 2026-04-02.

12. Revision Summary

• v1.2 (2026-04-02): Expanded requirements coverage for virtual/hybrid event options, ticket tiers/additional fees, job apply entrypoint, enhanced email template operations, and updated core-entity inventory.
• v1.1 (2026-04-02): Major consolidation of platform modules (events, payments, donations, mentorship, resumes, RBAC, system admin).