Objective
A single source of truth for base NFRs and FRs applicable across all features.
Requirements
Category | Requirement | Notes |
---|---|---|
Non-Functional Requirements (NFRs) | Performance | Response time must not exceed 100ms for 99% of API requests. Response time must not exceed 500ms for 99% of page load. System should handle up to 1000 concurrent users without degradation |
Scalability | Application must scale horizontally to handle an increase in traffic without performance loss.APIs must support scaling to 5x the expected daily traffic.At an instance level, capability to manage 100B monthly events. | |
Security | All APIs must support OAuth 2.0 or higher for authentication.Data must be encrypted at rest and in transit (AES-256 or higher encryption). | |
Availability | The system should have 99.99% uptime (including scheduled maintenance windows). | |
Maintainability | All modules must support backward compatibility for at least one previous version.Code should adhere to defined coding standard and be covered by 90%-unit tests.Code should be covered by 80%-automation testing, of which critical subset runs once-a-day and reports are maintained. | |
Compliance | The product should comply with SOC2, DPDP, GDPR, IS0 27001, IS0 27002, IS0 27018 and IS0 27701.At an instance level, as needed we should comply with HIPAA compliance.At an instance level, Data localization will need to be enforced.All logs should be available for a period of 6 months and any log linked to an incident or of criticality to be isolated and stored for a period of 12 months minimum or till resolution, whichever is later. | |
Usability | The interface should be intuitive and provide clear error messages for any failed operations.All CU interfaces should support range of device sizes from Tablet (iPads, Samsung Galaxy Tab, Pixel Tab) to Laptops and Monitors (65”)All Reporting, Analytics, Settings Interfaces should support range of device sizes from Mobile devices to Laptops and Monitors (65”) | |
Secure Release Management | Conduct an automated secure source code review prior to every release?Automated secure source code tools to include Static Application Security Testing (SAST)Automated secure source code tools to include Dynamic Application Security Testing (DAST)Automated secure source code tools to include the ability to crawl and test Rich Internet Applications (RIA) – (e.g., JavaScript, Ajax frameworks)Secure code reviews to include Fuzz testing (e.g., small numbers, large numbers, negative values, binary sequences, command line inputs, random values, etc.)Identified security vulnerabilities remediated prior to promotion to production | |
Functional Requirements (FRs) | Authentication and Authorization | Must support Single Sign-On (SSO) via OAuth 2.0 or higher.MFA/ 2FA to be required by default for any user who is not logging in via an SSO.Users should have role-based access control (RBAC) for feature sets |
Data Management | All customer data must be editable by users with sufficient permissions.Changes to data must be auditable with timestamps and the customer user who made changes. | |
API Requirements | All services should expose RESTful APIs with standardized response formats (JSON).APIs must support pagination for datasets larger than 100 records.All PII information to be shared only in hashed format over API calls.Ability to manage throughput at an account/ service level.Client should be able to manage (enabled, disable, RBAC, etc.) access to their APIsA self-service kill switch available to clients to disable an API in the event of a security incident (e.g., DoS) | |
Integrations | System must integrate with external platforms via API. | |
Notifications | Users must receive email notifications for critical actions (e.g., approval required, task completion).All notifications should be readable in notification center.Notification preferences should be customizable. | |