UXPROD-4070 NFR Scorecard
Quality Attribute | NFR ID | Non-Functional Requirement | Preliminary Analysis (Before feature started)- Date and Status | Final Analysis (After feature completed) - Date and Status | Notes and Comments | |
|---|---|---|---|---|---|---|
| 1 | Availability | NFR.Baseline.Availability.1 | Modules are designed and implemented following the Stateless principle | COMPLIANT | ||
| 2 | NFR.Baseline.Availability.2 | Load/performance testing must be conducted for at least 2 instances | ||||
| 3 | Manageability | NFR.Baseline.Manageability.1 | Application logs are collected in a unified form and location | COMPLIANT | This is implemented in the folio-spring-base library. | |
| 4 | NFR.Baseline.Manageability.2 | All custom configuration values are placed in the settings, not in the program code | COMPLIANT | |||
| 5 | Performance | NFR.Baseline.Performance.1 | Components are performance tested and compared to the prior release baseline; performance may not degrade more than 5% in exceptional cases | NOT VERIFIED | Opening/editing a profile should not degrade. | |
| NFR.ReadingRoom.Performance.1 | The solution should support a maximum of 25 simultaneous requests to reading rooms API (admit/deny access) in LoC. The single request should be completed in under <60 or TBD> seconds. | NOT VERIFIED | Use approach: Performance Testing With Karate Framework | |||
| 6 | Security | NFR.Baseline.Security.1 | Tenant data must be isolated from other tenants | COMPLIANT | Based on the assumption: RR and patron data in the central tenant of LoC | |
| 7 | NFR.Baseline.Security.2 | Secrets (such as usernames, passwords, API keys, and/or their combinations) are not stored in source repositories (i.e. Github) | COMPLIANT | Check the results of the sonar security scan after implementation is done. | ||
| 8 | NFR.Baseline.Security.3 | No sensitive information in logs (logins, passwords, API keys) | COMPLIANT | |||
| 9 | NFR.ReadingRoom.Security.1 |
| COMPLIANT | List all the fields that are present in read-only API for patron records and confirm with LoC that it can be accessed by the role of Security Officer | ||
| 10 | Testability | NFR.Baseline.Testability.1 | Unit-test coverage for new code created/changed during the implementation of the feature >= 80% | COMPLIANT | ||
| 11 | NFR.Baseline.Testability.2 | E2E-test coverage - # of automated test cases from test rail to # of all test cases at a particular feature | COMPLIANT | |||
| 12 | NFR.Baseline.Testability.3 | Karate-test coverage - # of test to # of new endpoints that were created (or existing endpoints that were changed) in the feature scope | COMPLIANT | |||
| 13 | Accessibility | NFR.MarcValidation.Accessibility.1 | Automated tests for WCAG 2.1 AA compliance | COMPLIANT | Provide the link with the results of the accessibility tests | |
| 14 | Maintainability | NFR.ReadingRoom.Maintainability.1 | The solution should be independent and loosely coupled as the FOLIO core modules do not include the feature | COMPLIANT | The implementation will be done as a separate module (microservice). This will provide a loose coupling of the solution. | |
| 15 | Extensibility | NFR.ReadingRoom.Extensibility.1 | The solution should allow extending the room access feature’s capability with additional functionality | COMPLIANT |