Quality Requirements

Table of Contents

• Priority Matrix
• Usability
• Performance
• Reliability
• Security
• Maintainability
• Compatibility

Priority Matrix

Priority Matrix for University Platform Migration:

Technical Risk → Business Importance ↓	L	M	H
L		QAS401
M		QAS201, QAS202	QAS302
H	QAS102	QAS301, QAS501	QAS101, QAS301

Key:

• Rows - Business Importance
• Columns - Technical Risk
• L - low, M - medium, H - high
• Elements - identifiers of quality requirements scenarios

Priority Explanation:

The priority matrix is organized by Business Importance (rows) and Technical Risk (columns). This prioritization approach ensures that we focus on delivering maximum value while managing technical complexity effectively. The rationale for each priority level is explained below.

Critical Priority (H, H)

1. (H, H): QAS101 - Zero downtime migration

   • Business Rationale: The platform serves active users who depend on continuous availability. Extended downtime would disrupt university events and user activities, damaging trust and adoption.
   • Technical Risk Rationale: Server migration involves complex data transfer, DNS changes, and service coordination. Achieving ≤1 hour downtime requires meticulous planning, fallback strategies, and real-time monitoring.
   • Why Critical: Service continuity is non-negotiable for user trust and platform credibility.

2. (H, H): QAS301 - Data integrity during migration

   • Business Rationale: User data, event information, and social connections must remain intact. Data loss would be irreparable and violate user trust.
   • Technical Risk Rationale: Data transfer between servers risks corruption, inconsistency, or partial loss. Ensuring 100% integrity requires validation at multiple levels.
   • Why Critical: Without data integrity, the platform loses all value.

High Priority

1. (H, M): QAS201 - Cross-platform response time

   • Business Rationale: Users expect consistent, fast performance whether using mobile app or Telegram Mini App. Slow response times directly impact user satisfaction and retention.
   • Technical Risk Rationale: Synchronizing data across platforms while maintaining sub-2 second response times requires optimized APIs and efficient state management.
   • Why High Priority: Performance directly correlates with user adoption and satisfaction.

2. (H, M): QAS501 - Platform compatibility

   • Business Rationale: All features must work seamlessly on both platforms. Feature disparity would confuse users and reduce platform utility.
   • Technical Risk Rationale: Mobile apps and Telegram Mini Apps have different capabilities and constraints. Achieving 95%+ feature parity requires careful abstraction and platform-specific adaptations.
   • Why High Priority: Cross-platform consistency is a core project requirement.

3. (M, H): QAS302 - Authentication reliability

   • Business Rationale: Users must reliably access their accounts through both email and Telegram. Authentication failures block all platform usage.
   • Technical Risk Rationale: Supporting multiple auth methods (email, Telegram) increases complexity. Edge cases in session management and token validation require robust handling.
   • Why High Priority: High technical risk demands early attention to prevent blocking user access.

Medium Priority

1. (M, M): QAS202, QAS203 - Map performance & availability

   • Business Rationale: Maps enhance event discovery but aren't critical for basic platform usage. Users can still browse events without maps.
   • Technical Risk Rationale: Automated map updates and third-party API integration introduce dependencies and potential failure points. Risk is manageable with proper error handling.
   • Why Medium Priority: Valuable feature but not core to platform functionality.

2. (H, L): QAS102 - Profile redesign usability

   • Business Rationale: Profile usability directly impacts daily user experience and engagement. However, existing profile works, making this an enhancement.
   • Technical Risk Rationale: UI redesign is low risk with modern frameworks. Main challenge is design quality, not technical complexity.
   • Why Medium Priority: High business value but low technical risk allows iterative implementation.

Low Priority

1. (L, M): QAS401 - Code maintainability
   • Business Rationale: Code quality doesn't directly impact end users in initial releases. However, it's crucial for long-term maintenance and feature additions.
   • Technical Risk Rationale: Maintaining 70%+ test coverage requires ongoing discipline but is achievable with proper practices.
   • Why Low Priority: Important for sustainability but can be addressed incrementally post-MVP.

Prioritization Strategy Summary:

The prioritization follows a risk-adjusted value approach:

• Critical items (H, H) ensure platform survival and data integrity
• High priority items focus on core user experience and authentication
• Medium priority items enhance functionality without blocking core usage
• Low priority items support long-term sustainability

This approach ensures we deliver a reliable, functional platform first, then enhance features based on user feedback.

Usability

QAS101

Zero Downtime Migration

• Source: End users (students, faculty, event organizers)
• Stimulus: Migration of services from external to university servers
• Artifact: Entire platform infrastructure
• Environment: Production environment during migration window
• Response: Platform remains accessible throughout migration with no service interruption
• Response Measure: Total downtime ≤ 1 hour, with no single service interruption exceeding 15 minutes

QAST101-1

Test: Conduct migration during low-usage hours with comprehensive monitoring. Measure actual downtime across all services (authentication, event management, social features).

Success: Total cumulative downtime ≤ 1 hour, with no user-visible errors during migration.

QAS102

Intuitive Profile Redesign

• Source: End users (all platform users)
• Stimulus: User accesses redesigned profile page
• Artifact: User profile interface
• Environment: Normal platform usage
• Response: Users can navigate profile sections and complete common tasks without confusion
• Response Measure: 85% of users complete key profile tasks within 2 minutes without assistance

QAST102-1

Test: Observe 20 users performing common tasks: viewing their events, checking followers, editing profile information. Measure completion time and error rate.

Success: 17 of 20 users complete all tasks within 2 minutes without asking for help.

QAS103

Follow Request Clarity

• Source: Users managing social connections
• Stimulus: User receives or sends follow requests
• Artifact: Follow request interface and notifications
• Environment: Social interaction context
• Response: Users clearly understand request status (pending, accepted, rejected) and can take appropriate action
• Response Measure: 90% of users correctly interpret follow request status and available actions

QAST103-1

Test: Present users with various follow request scenarios and ask them to explain the status and next steps.

Success: 90% of responses correctly identify status and appropriate actions.

Performance

QAS201

Cross-Platform Response Time

• Source: Users interacting with platform features
• Stimulus: User performs common actions (view events, send requests, update profile)
• Artifact: Mobile app and Telegram Mini App interfaces
• Environment: Normal network conditions (4G/WiFi)
• Response: Actions complete with consistent response times across both platforms
• Response Measure: 95% of actions complete within 2 seconds on both platforms, with ≤ 500ms variance between platforms

QAST201-1

Test: Automate execution of 100 common user actions on both platforms under various network conditions. Measure response times and cross-platform variance.

Success: 95% of actions ≤ 2 seconds on both platforms, variance ≤ 500ms.

QAS202

Map Loading Performance

• Source: Users accessing map view
• Stimulus: User opens map to browse events by location
• Artifact: Map visualization component
• Environment: Initial load and subsequent navigation
• Response: Map loads and displays event markers efficiently
• Response Measure: Initial map load ≤ 3 seconds, subsequent interactions ≤ 1 second response

QAST202-1

Test: Measure map load times across 50 sessions with varying event densities (10-20 events).

Success: Average initial load ≤ 3 seconds, interaction response ≤ 1 second.

QAS203

Notification Delivery Speed

• Source: System sending user notifications
• Stimulus: Event creation, follow request, or other trigger generates notification
• Artifact: Notification delivery system
• Environment: Normal operation
• Response: Notifications reach intended users promptly
• Response Measure: 90% of notifications delivered within 30 seconds of trigger event

QAST203-1

Test: Generate 100 notification triggers (event creations, follow requests) and measure delivery time to recipient devices.

Success: 90% delivered within 30 seconds across both platforms.

Reliability

QAS301

Data Integrity During Migration

• Source: System performing server migration
• Stimulus: Transfer of all user data, events, and relationships
• Artifact: Data migration process
• Environment: Migration window with live data
• Response: All data transferred completely and accurately
• Response Measure: 100% data integrity verified through pre/post-migration validation (record counts, checksums, sample verification)

QAST301-1

Test: Perform trial migration in staging environment with production data snapshot. Validate complete data transfer: user accounts, events, follow relationships, notifications.

Success: Zero data loss or corruption. All relationships intact.

QAS302

Authentication Availability

• Source: Users attempting to log in
• Stimulus: User initiates login via email/password or Telegram
• Artifact: Authentication service
• Environment: Normal and peak usage periods
• Response: Authentication service remains available and responsive
• Response Measure: 99.9% authentication success rate, 99.5% availability during peak hours

QAST302-1

Test: Monitor authentication success rates over 30-day period, including peak usage times (event registration periods).

Success: ≥ 99.9% success rate, ≥ 99.5% availability during peaks.

QAS303

Event Creation Reliability

• Source: Users creating new events
• Stimulus: User submits event creation form
• Artifact: Event management system
• Environment: Concurrent usage scenarios
• Response: Events are reliably created and notifications sent
• Response Measure: 99.5% of valid event submissions successfully created and visible within 10 seconds

QAST303-1

Test: Simulate 100 concurrent event creations with varying data sizes. Verify all events appear in database and trigger appropriate notifications.

Success: 95+ events created successfully, all visible within 5 seconds.

Security

QAS401

Secure Authentication

• Source: Users accessing platform
• Stimulus: User login, password reset, or session management
• Artifact: Authentication and authorization system
• Environment: All usage scenarios
• Response: All authentication flows follow security best practices
• Response Measure: Zero critical vulnerabilities in security audit, all passwords and tokens properly encrypted

QAST401-1

Test: Conduct security audit of authentication flows: password storage, reset tokens, session management, Telegram integration.

Success: No critical findings. All sensitive data properly encrypted.

QAS402

Data Privacy

• Source: Users managing their information
• Stimulus: Users access, modify, or share personal data
• Artifact: Data access controls
• Environment: Normal and multi-user scenarios
• Response: Users can only access authorized data; privacy settings respected
• Response Measure: Zero unauthorized data access incidents in penetration testing

QAST402-1

Test: Attempt unauthorized access to user data across all endpoints: profile information, events, follow relationships.

Success: All unauthorized access attempts properly blocked.

Maintainability

QAS501

Code Quality and Testability

• Source: Development team maintaining platform
• Stimulus: Need to modify or extend functionality
• Artifact: Source code and test suite
• Environment: Maintenance and feature development phases
• Response: Changes can be made confidently with comprehensive testing
• Response Measure: 70%+ code coverage, all critical paths tested

QAST501-1

Test: Measure test coverage after implementing new features. Track regression test pass rates.

Success: Maintain 70%+ line coverage. Zero regressions in critical features after changes.

Compatibility

QAS601

Cross-Platform Feature Parity

• Source: Users switching between platforms
• Stimulus: User accesses same feature on mobile app and Telegram Mini App
• Artifact: Feature implementations on both platforms
• Environment: Normal usage across devices
• Response: Features behave consistently with synchronized data
• Response Measure: 95%+ feature parity, real-time data sync across platforms

QAST601-1

Test: Execute identical user journeys on both platforms. Verify feature availability, behavior, and data synchronization.

Success: 95% of features available and consistent. Data sync ≤ 5 seconds.

QAS602

Telegram Integration Compatibility

• Source: Users accessing via Telegram Mini App
• Stimulus: User authenticates and uses platform through Telegram
• Artifact: Telegram Mini App integration
• Environment: Various Telegram versions and platforms
• Response: Seamless authentication and feature access via Telegram
• Response Measure: 98% success rate for Telegram-based operations

QAST602-1

Test: Execute core user journeys through Telegram Mini App across different Telegram versions and platforms (mobile, desktop).

Success: 98% operation success rate, seamless authentication flow.