- Introduction
The client for this project is WestJet, a Canadian airline headquartered in Calgary, Alberta. WestJet has over 15,000 employees and in 2025 served more than 22.6 million guests.[1] The report documents the functional and non-functional requirements for the Digital Profile Apps Admin Panel, an internal administrative tool for managing platform features and maintaining cache consistency across WestJet’s Digital Platform Services.
Functional Requirements (FRs) define what a system must do. They describe the specific features, direct user actions, business logic, workflows, and inputs/outputs necessary for the application to fulfill its intended purpose.[2]
Non-Functional Requirements (NFRs) define how the system must perform those functions. They specify criteria such as performance, security, reliability, maintainability, compliance, and developer workflow standards.[2]
Several work meetings were held with the client in which a technical specification was provided and reviewed. The outcome was a list of functional and non-functional requirements for the entire project, which are listed below. These requirements may evolve over time as the project begins taking shape and features are delivered. Several requirements require deliverables from internal teams or 3rd parties and are indicated as such. Fulfillment of these requirements depends on collaborators delivering features and/or services to be used in the project. If it is not possible for features and services to be delivered, requirements will be revised to best maintain project features as identified by the client.
2. Functional Requirements
| ID | Requirement | Must Have | Nice to Have | Stretch Goal | Collab-oration required |
| FR-01 | User can log in via enterprise Single Sign-On (SSO) integrated with Azure AD using ForgeRock or SailPoint. | ✓
|
✓
|
||
| FR-02 | System restricts access exclusively to authenticated internal staff (no anonymous or guest access). | ✓ | |||
| FR-03 | System persists user session across browser reloads via token refresh mechanisms. | ✓ | |||
| FR-04 | System automatically logs user out after an idle timeout period (e.g., 30 minutes of inactivity). | ✓ | |||
| FR-05 | System invalidates refresh tokens and clears session tokens upon user logout. | ✓ | |||
| FR-06 | System synchronizes logout across multiple browser tabs (logging out in one tab logs out all tabs). | ✓ | |||
| FR-07 | User can perform DPS cache and data lookups; successful queries render formatted JSON with a functional copy button, while switching tabs resets search input and clears previous results. | ✓ | |||
| FR-08 | Lookup interface dynamically adapts UI labels (e.g., “Search conversions” based on Lookup Type), displays a loading spinner that disables concurrent lookups while in flight, and suppresses the result panel on invalid keys or API failures. | ✓ | |||
| FR-09 | System enforces client-side form validation before executing lookups (requiring a selected Partner, exactly 9 digits for WestJet ID, and exactly 32 hex characters for Hex Identifier). | ✓ | |||
| FR-10 | User with cache-admin or super-admin role can trigger DPS cache clearing via protected endpoints, requiring confirmation and displaying loading, timestamped success, or error states with retry options. | ✓ | |||
| FR-11 | System fetches and displays feature flag configurations from Azure Blob Storage in a sortable, filterable table. | ✓ | ✓
|
||
| FR-12 | User with feature-flag-manager or super-admin role can toggle feature flag states on/off, requiring explicit confirmation before persisting atomic JSON updates back to Azure Blob Storage. | ✓ | ✓
|
||
| FR-13 | System automatically rolls back the UI toggle to its previous state and presents an error notification if the Azure Blob update fails. | ✓ | |||
| FR-14 | System dynamically adjusts UI visibility (shows, hides, or disables action buttons) based on Role-Based Access Control (RBAC) claims in the OAuth token. | ✓
|
✓
|
||
| FR-15 | Read-only users can inspect cache status and view feature flag tables without write/toggle permissions. | ✓ | |||
| FR-16 | System displays user-friendly toast feedback notifications for success and error states on all operational tasks. | ✓ | |||
| FR-17 | System records comprehensive audit logs (user ID, timestamp, operation type, and outcome) for all sensitive operations (logins, cache clearing, feature flag modifications). | ✓ | |||
| FR-18 | System includes version control and rollback functionality for feature flag JSON configurations. | ✓ | |||
| FR-19 | User with super-admin role can create or permanently delete feature flags. | ✓ | ✓ |
3. Non-Functional Requirements
| ID | Requirement | Must Have | Nice to Have | Stretch Goal | Collab-oration required |
| NFR-01 | All network communication (browser to backend, backend to API) must be encrypted via HTTPS (TLS 1.2+) with HSTS enforced. | ✓ | |||
| NFR-02 | Frontend tokens must be secured against XSS using HttpOnly, Secure, and SameSite cookies (or sessionStorage with mandatory CSRF tokens). | ✓ | |||
| NFR-03 | State-changing operations must implement Cross-Site Request Forgery (CSRF) protection mechanisms. | ✓ | |||
| NFR-04 | Token introspection validation latency must not exceed 100 ms per request (utilizing cached introspection where applicable). | ✓
|
|||
| NFR-05 | Single Sign-On and token issuance must conform to OAuth 2.0 / OIDC standards using Authorization Code Flow with PKCE. | ✓ | ✓
|
||
| NFR-06 | Application must enforce network boundary constraints (accessible only via corporate network / VPN or forced OAuth redirect). | ✓ | ✓
|
||
| NFR-07 | System must ship audit logs to an enterprise SIEM platform (Splunk/ELK) capturing user identity, timestamp, action, result, and source IP. | ✓ | ✓
|
||
| NFR-08 | Unit and integration test suites must achieve at least 80% code coverage across critical application paths using Vitest and Vue Testing Library. | ✓ | |||
| NFR-09 | UI components must be isolated, documented, and visually verifiable within Storybook for design continuity. | ✓ | |||
| NFR-10 | Codebase must adhere to TypeScript strict typing, ESLint quality rules, and Stylelint SCSS guidelines. | ✓ | |||
| NFR-11 | Auth solution must be supportable by WestJet platform team (vendor SLA required) | ✓ | ✓
|
4. References
[1] WestJet. (2026). WestJetting Since ‘96. Retrieved from https://www.westjet.com/en-ca/who-we-are/brand
[2] L. Bass, P. Clements, R. Kazman. 2012. Software Architecture in Practice (3rd ed.). Pearson Education, Upper Saddle River, NJ.