Non-Functional Requirements

1. Purpose

This document defines the non-functional requirements (NFRs) for SaludVital, a healthcare appointment management system.

These requirements establish the quality attributes, security expectations, operational constraints, compatibility standards, and verification criteria that guide the design, development, testing, and maintenance of the application.

SaludVital must provide a secure, reliable, maintainable, accessible, and responsive experience across supported devices and environments.

2. Scope

These requirements apply to:

• The web application and user interface.
• Backend services and application architecture.
• Authentication and authorization mechanisms.
• Database operations and data integrity.
• Patient, doctor, and administrator workflows.
• Appointment scheduling and concurrent booking operations.
• Application logging and error handling.
• Supported browsers and device categories.
• Deployment, backup, and recovery procedures.

These requirements describe the expected quality and operational characteristics of the system rather than individual business features.

3. Requirement Classification

Each requirement has a unique identifier, a priority, and a verification method.

3.1 Priority Levels

• Must: Essential requirement for the system's expected quality, security, or integrity.
• Should: Important requirement that should be implemented unless a justified exception is approved.
• Could: Desirable improvement that may be implemented when resources permit.

3.2 Verification Status

A requirement is not considered verified merely because it is documented. Evidence must demonstrate that the requirement has been satisfied.

Quantitative targets proposed in this document remain provisional until approved by the project stakeholders.

3.3 Verification Methods

Depending on the requirement, verification may include:

• Automated unit, integration, and end-to-end tests.
• Code and configuration reviews.
• Database constraint and transaction tests.
• Browser and responsive layout checks.
• Accessibility assessments.
• Performance and concurrency measurements.
• Deployment and recovery exercises.
• Documentation reviews.

4. Security Requirements

NFR-SEC-001 — Password Protection

Priority: Must

User passwords must be stored using an appropriate one-way password hashing algorithm. Plain-text passwords must never be stored or logged.

Verification: Inspect the authentication implementation and database records to confirm that passwords are hashed and are not exposed in logs or application responses.

NFR-SEC-002 — Authentication

Priority: Must

Protected resources must require valid authentication. Invalid, expired, or missing credentials must not grant access to protected functionality.

Verification: Execute automated tests covering valid credentials, invalid credentials, expired tokens, and unauthenticated requests.

NFR-SEC-003 — Role-Based Authorization

Priority: Must

Access to protected functionality must be restricted according to the user's assigned role. Patients, doctors, and administrators must not access resources or operations outside their authorized permissions.

Verification: Test permitted and denied operations for each role, including attempts to access another user's protected information.

NFR-SEC-004 — Token and Session Handling

Priority: Must

Authentication tokens and session credentials must be handled securely. Token validation must include the applicable signature, expiration, and required claims. Sensitive credentials must not be exposed in URLs or application logs.

Verification: Test invalid signatures, expired tokens, missing tokens, and unauthorized access attempts. Review the applicable cookie and session settings.

NFR-SEC-005 — Secret Management

Priority: Must

Database passwords, JWT secrets, API credentials, and other sensitive configuration values must be supplied through environment-specific configuration or an appropriate secrets-management mechanism.

Real secrets must not be committed to the repository. Example environment files must contain placeholders rather than actual credentials.

Verification: Review environment configuration, .gitignore, .env.example, and repository changes for exposed credentials.

NFR-SEC-006 — Input Validation

Priority: Must

User input must be validated on the server before it is processed or persisted. Validation must not rely exclusively on client-side checks.

Verification: Test malformed input, invalid data types, missing required fields, and common injection attempts.

5. Privacy and Data Protection Requirements

NFR-PRV-001 — Protection of Personal and Medical Information

Priority: Must

Personal and medical information must only be accessible to authorized users for legitimate application purposes. Sensitive information must not be unnecessarily exposed through responses, error messages, logs, or URLs.

Verification: Test access controls and inspect responses and logs for unauthorized disclosure.

NFR-PRV-002 — Data Minimization

Priority: Must

The application must collect, process, and expose only the information necessary for its defined functionality. Sensitive fields must not be returned to clients that do not require them.

Verification: Review data models, API responses, views, and access permissions.

NFR-PRV-003 — Secure Communication

Priority: Must

Production communication involving authentication credentials or personal information must use HTTPS.

Verification: Verify HTTPS configuration in the deployment environment before production release.

NFR-PRV-004 — Data Retention and Deletion

Priority: Should

The project must define appropriate retention, archival, and deletion procedures for personal and medical information, taking into account applicable legal obligations and operational requirements.

Verification: Review the documented retention policy and verify that the implemented procedures follow the approved policy.

6. Performance Requirements

NFR-PER-001 — Response Time

Priority: Should

The project proposes a target of responding to at least 95% of ordinary application requests within two seconds under an agreed normal test workload.

This target is provisional and must be approved by the project stakeholders before it becomes a binding acceptance threshold.

Verification: Measure response times using a documented workload, test environment, request volume, and measurement period.

NFR-PER-002 — Database Query Efficiency

Priority: Should

Database queries must avoid unnecessary operations and excessive data retrieval. Indexes and query optimizations should be applied where justified by query patterns and measurements.

Verification: Inspect important queries and review query plans or performance measurements.

NFR-PER-003 — Concurrent Requests

Priority: Should

The application must handle concurrent requests without unexpected failures or inconsistent results. Required concurrency capacity must be agreed upon before performance acceptance.

Verification: Execute concurrent-request tests and document the workload, error rate, response times, and observed resource usage.

NFR-PER-004 — Resource Efficiency

Priority: Should

The application should use server resources, database connections, memory, and client-side resources efficiently. Resource-intensive operations must not unnecessarily block unrelated requests.

Verification: Measure resource consumption during representative workloads and review database connection handling.

7. Reliability and Availability Requirements

NFR-REL-001 — Predictable Error Handling

Priority: Must

The application must handle expected application and infrastructure errors without exposing internal stack traces, secrets, or sensitive information to end users.

Verification: Test validation errors, unavailable dependencies, database failures, and unexpected server errors.

NFR-REL-002 — Consistent Failure Behavior

Priority: Must

A failed operation must not leave the system in a partially updated or inconsistent state. Database transactions must be used where required to preserve consistency.

Verification: Test transaction rollback and failure scenarios for operations that modify related records.

NFR-REL-003 — Availability Target

Priority: Should

A production availability target must be agreed upon before deployment. The target must specify the measurement period, planned maintenance exclusions, monitoring method, and calculation method.

Verification: Validate the agreed target using deployment monitoring and availability records.

NFR-REL-004 — Graceful Dependency Failure

Priority: Should

When a required external service or infrastructure dependency becomes unavailable, the application must handle the failure predictably, provide an appropriate user-facing message, and avoid corrupting application data.

Verification: Simulate unavailable dependencies and confirm that failures are handled without inconsistent database state or disclosure of sensitive information.

8. Data Integrity and Concurrency Requirements

NFR-DAT-001 — Appointment Consistency

Priority: Must

Appointment operations must preserve database integrity and enforce the applicable scheduling rules. Invalid relationships and inconsistent appointment states must be rejected.

Verification: Test database constraints, valid state transitions, and invalid appointment operations.

NFR-DAT-002 — Prevention of Conflicting Reservations

Priority: Must

Concurrent appointment booking requests must not create conflicting active reservations for the same doctor and time slot.

Availability validation and persistence must be coordinated using appropriate transactional and database concurrency controls.

Verification: Run concurrent booking tests against the same time slot and confirm that conflicting active appointments cannot be created.

NFR-DAT-003 — Atomic Rescheduling

Priority: Must

Rescheduling must preserve data consistency. The system must not leave an appointment in an invalid state if the rescheduling operation fails. The applicable doctor and availability rules must be enforced.

Verification: Test successful rescheduling, unavailable slots, concurrent rescheduling attempts, and transaction failures.

NFR-DAT-004 — Referential Integrity

Priority: Must

Relationships between users, patients, doctors, appointments, and other related records must remain consistent. Database constraints and application validation must prevent invalid references.

Verification: Test foreign key constraints, invalid references, and relevant deletion or update scenarios.

9. Usability and Accessibility Requirements

NFR-USA-001 — Understandable User Feedback

Priority: Should

User-facing messages must be understandable, presented in Spanish, and explain validation failures or unsuccessful operations without revealing internal technical details.

Verification: Review relevant views and test common validation and error scenarios.

NFR-USA-002 — Consistent Navigation

Priority: Should

The interface must provide consistent navigation and clearly distinguish functionality according to the user's role.

Verification: Review the main user journeys for patients, doctors, and administrators.

NFR-USA-003 — Accessibility

Priority: Must

The interface must support keyboard navigation, visible focus, appropriately associated form labels, meaningful page structure, sufficient contrast, and accessible error feedback.

Essential information must not be communicated exclusively through color, hover, or a particular input device.

Verification: Perform keyboard-only checks, automated accessibility scans, and manual checks on representative pages.

NFR-USA-004 — Readability Across Screen Sizes

Priority: Must

Text, controls, forms, and important information must remain readable and usable across supported screen sizes, including small mobile screens and large television displays.

Verification: Inspect representative pages at narrow and wide viewport sizes and confirm that essential content is not clipped or made inaccessible.

10. Cross-Device Compatibility and Responsive Design Requirements

NFR-CMP-001 — Responsive Design Across Device Categories

Priority: Must

SaludVital must provide a responsive user interface that adapts to mobile phones, tablets, laptops, desktop computers, large monitors, and compatible smart TVs with supported web browsers.

The layout, typography, spacing, navigation, forms, tables, dialogs, and interactive components must adapt to available viewport dimensions and input capabilities.

The application must not depend on a single screen size, device orientation, or input method.

Verification: Test representative viewport sizes across all supported device categories. Verify that authentication, registration, appointment scheduling, and role-specific workflows remain usable.

NFR-CMP-002 — Mobile and Touch Usability

Priority: Must

On mobile and other touch-enabled devices, interactive elements must be usable with touch input. Controls must have sufficient spacing, readable text, visible interaction states, and appropriate behavior when the on-screen keyboard is displayed.

Core workflows must not require a mouse or hover-only interactions.

Verification: Test core workflows using mobile viewport emulation and, when available, physical touch-enabled devices.

NFR-CMP-003 — Large Screens and Smart TV Compatibility

Priority: Must

On laptops, desktop computers, large monitors, and compatible smart TVs, SaludVital must use available screen space appropriately without making content excessively stretched, difficult to read, or difficult to navigate.

The interface must support the available input methods of the target environment, including keyboard navigation and remote-control navigation where supported.

The application must not assume that every smart TV has a modern browser or supports all web technologies.

Verification: Test representative large-screen layouts and keyboard navigation. Validate compatibility on selected smart TV browsers or emulated environments where feasible. Document unsupported browsers and known limitations.

NFR-CMP-004 — Viewport and Orientation Adaptation

Priority: Must

The interface must adapt to portrait and landscape orientations on supported devices. Content must remain readable and interactive when the viewport changes size, the device rotates, or browser interface elements alter the available display area.

Verification: Resize the viewport and test supported orientations. Confirm that essential content and controls remain accessible.

NFR-CMP-005 — Content Reflow and Horizontal Scrolling

Priority: Must

Core application pages must reflow to the available viewport width without unintended horizontal scrolling.

Where wide data tables or specialized content genuinely require horizontal scrolling, the affected region must remain usable without causing the entire page to overflow.

Verification: Inspect representative pages at narrow mobile widths, tablet widths, desktop widths, and large-screen widths.

NFR-CMP-006 — Browser Compatibility

Priority: Must

SaludVital must support an explicitly documented set of target browsers and versions. Compatibility must be assessed separately for desktop, mobile, and smart TV environments.

The supported browser matrix must identify known limitations and be reviewed before release.

Verification: Execute representative functional and visual checks in each agreed target browser.

NFR-CMP-007 — Responsive Component Consistency

Priority: Must

Shared interface components, including navigation, forms, buttons, notifications, dialogs, and appointment views, must maintain consistent behavior and visual hierarchy across supported screen sizes.

Device-specific adaptations must not remove essential functionality or bypass authentication and authorization rules.

Verification: Review shared components at representative viewport sizes and test equivalent user workflows across supported device categories.

NFR-CMP-008 — Responsive Accessibility

Priority: Must

Responsive layouts must preserve accessibility, including readable content, keyboard accessibility, visible focus, meaningful labels, sufficient contrast, and usable controls at supported screen sizes.

The interface must not rely exclusively on color, hover, or a particular input device to communicate essential information.

Verification: Perform keyboard-only checks, representative accessibility scans, and manual checks at mobile and large-screen viewport sizes.

NFR-CMP-009 — Responsive Performance

Priority: Should

Pages must remain usable on supported devices and connection conditions. Images, stylesheets, scripts, and other resources should be sized and loaded efficiently to avoid unnecessary delays, particularly on mobile devices and lower-powered smart TV hardware.

Verification: Measure page-load and interaction performance on representative devices or documented emulation profiles. Record the test environment and results.

NFR-CMP-010 — Preservation of Essential Functionality

Priority: Must

All essential workflows available to a user role must remain accessible on the supported device categories, unless a specific limitation is documented and approved.

Responsive adaptations must not unintentionally hide essential actions, remove validation, or change authorization behavior.

Verification: Compare the essential patient, doctor, and administrator workflows across representative supported devices.

11. Maintainability and Code Quality Requirements

NFR-MNT-001 — Modular Architecture

Priority: Must

The application must maintain a clear separation of responsibilities between routes, controllers, middleware, models, configuration, and views, following the established project architecture.

Verification: Review the project structure and confirm that new functionality follows the documented architectural conventions.

NFR-MNT-002 — Coding Conventions

Priority: Must

Source code must follow the project's established naming, formatting, and linting conventions. Changes must avoid unnecessary duplication and maintain clear responsibilities.

Verification: Run the configured linting and formatting checks.

NFR-MNT-003 — Automated Testing

Priority: Must

Changes to application behavior must include appropriate automated tests. Tests and required quality checks must pass before a change is integrated into the target branch.

Verification: Execute the configured test suite and quality checks in the development environment and applicable continuous integration workflow.

NFR-MNT-004 — Technical Documentation

Priority: Should

Important architectural decisions, configuration requirements, and operational procedures must be documented and kept consistent with the implemented system.

Verification: Review documentation changes alongside the corresponding implementation.

NFR-MNT-005 — Responsive Maintainability

Priority: Should

Responsive behavior should be implemented using reusable layout patterns, shared components, and consistent styling conventions rather than unnecessary device-specific duplication.

Verification: Review responsive styles and shared components for consistency, reuse, and unnecessary overrides.

12. Logging and Monitoring Requirements

NFR-LOG-001 — Operational Error Logging

Priority: Must

The application must record sufficient information about relevant operational errors to support diagnosis. Logs must not contain passwords, authentication tokens, secrets, or unnecessary personal and medical information.

Verification: Trigger representative errors and inspect the resulting logs for diagnostic usefulness and sensitive-data exposure.

NFR-LOG-002 — Security-Relevant Events

Priority: Should

Relevant security events, such as repeated authentication failures and denied access attempts, should be recorded in a manner appropriate to the deployment environment.

Verification: Test representative security events and confirm that the records do not expose sensitive credentials or information.

NFR-LOG-003 — Operational Visibility

Priority: Should

The production environment should provide appropriate visibility into application health, error rates, and service availability.

Verification: Review the monitoring design and validate health and error reporting in the deployment environment.

13. Backup and Recovery Requirements

NFR-REC-001 — Database Backup

Priority: Must

A backup procedure must be defined before production deployment. It must specify backup frequency, retention, storage protection, and responsibility for execution.

Verification: Review the documented procedure and confirm that backups can be created in the target environment.

NFR-REC-002 — Recovery Validation

Priority: Must

Database recovery must be tested before production readiness is approved. Recovery objectives, including the acceptable data-loss window and restoration time, must be agreed upon by the project stakeholders.

Verification: Perform a restoration exercise and record the outcome and measured recovery time.

NFR-REC-003 — Recovery Documentation

Priority: Should

The project should document the steps required to restore the application and its database after a significant failure.

Verification: Review the recovery procedure and perform a walkthrough or restoration exercise in a suitable environment.

14. Proposed Quantitative Targets and Pending Decisions

The following targets and decisions require stakeholder approval before they become binding acceptance thresholds.

Area	Proposed target or decision	Status
Response time	95% of ordinary requests within two seconds under an agreed workload	Provisional
Concurrent users	Define expected concurrent-user capacity	Pending approval
Availability	Define target and measurement period	Pending approval
Recovery	Define acceptable data-loss window and restoration time	Pending approval
Browser support	Document supported browser names and versions	Pending approval
Smart TV support	Select target TV browsers or document limitations	Pending approval
Responsive testing	Define representative viewport sizes and test devices	Pending approval
Accessibility	Define applicable accessibility standard and target conformance level	Pending approval
Data retention	Define retention and deletion rules based on applicable obligations	Pending approval

Quantitative requirements must be approved, measured, and supported by evidence before they are considered satisfied.

15. Verification and Traceability

Each requirement must be tracked by its identifier, priority, verification method, evidence, and status.

Requirements should be connected to relevant design documents, implementation tasks, and test cases where applicable.

Verification must distinguish between:

• Documented: The requirement and verification method are defined.
• Implemented: The corresponding solution exists.
• Tested: Verification has been executed and evidence recorded.
• Accepted: The responsible reviewer has confirmed that the acceptance criteria are satisfied.

Requirements dependent on deployment infrastructure must be validated in the appropriate environment rather than assumed to be satisfied during local development.

Responsive requirements must be verified through a combination of viewport testing, browser testing, keyboard and touch interaction checks, and physical-device validation where feasible.

16. Review and Maintenance

This document must be reviewed when significant changes affect application architecture, authentication, authorization, database design, responsive components, supported browsers, deployment, or integrations.

Changes to quantitative targets must be approved by the project stakeholders and reflected in relevant design documents and testing plans.

The document must remain consistent with the SaludVital architecture, database model, security requirements, responsive design approach, and software testing strategy.

17. Definition of Done

The non-functional requirements documentation is considered complete when:

• All requirements have unique identifiers and priorities.
• Each requirement includes a description and verification method.
• Security, privacy, performance, reliability, integrity, usability, accessibility, compatibility, maintainability, logging, and recovery are addressed.
• Responsive design explicitly covers mobile phones, tablets, laptops, desktop computers, large monitors, and compatible smart TVs.
• Provisional targets and unresolved stakeholder decisions are clearly identified.
• The document has been reviewed for consistency with the project architecture and testing strategy.
• The completed documentation has been reviewed and accepted through the project's agreed workflow.