UXPROD-4549 NFR Scorecard
Status | IN PROGRESS |
|---|---|
Date-time | Apr 4, 2024 |
Dev Team | Spitfire |
Architect | @Kalibek Turgumbayev |
Product Owner | @Khalilah Gambrell |
Scrum Master | @Natalia Zaitseva |
Team Lead | @Pavlo Smahin
|
Prod Ticket | |
Arch Ticket | |
Tech Design | |
Release | Ramsons (R2 2024) |
| 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 | Apr 4, 2024 COMPLIANT |
|
|
2 | NFR.Baseline.Availability.2 | Load/performance testing must be conducted for at least 2 instances | Apr 11, 2024 COMPLIANT |
| Check scalability on 2+ replicas. Need to check that in the case of two replicas the requests to one of the replicas do not impact the other replica. No perf testing is needed for R Release | |
3 | Manageability | NFR.Baseline.Manageability.1 | Application logs are collected in a unified form and location | Apr 11, 2024 COMPLIANT |
| The new module is based on a spring-folio-base library which provides compliance with this NFR |
4 | NFR.Baseline.Manageability.2 | All custom configuration values are placed in the settings, not in the program code | Apr 11, 2024 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 | Apr 11, 2024 NOT VERIFIED |
| Use approach: Performance Testing With Karate Framework
|
|
| NFR.MarcValidation.Performance.1 |
| Apr 11, 2024 NOT VERIFIED |
| |
6 | Security | NFR.Baseline.Security.1 | Tenant data must be isolated from other tenants | Apr 11, 2024 COMPLIANT |
|
|
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) | Apr 11, 2024 COMPLIANT |
|
| |
8 | NFR.Baseline.Security.3 | No sensitive information in logs (logins, passwords, API keys) | Apr 11, 2024 COMPLIANT |
|
| |
| NFR.MarcValidation.Security.1 | The solution should provide different permissions to allow users to create/edit/view MARC bib validation rules | Apr 4, 2024 COMPLIANT |
| ||
9 | Testability | NFR.Baseline.Testability.1 | Unit-test coverage for new code created/changed during the implementation of the feature >= 80% | Apr 11, 2024 COMPLIANT |
|
|
10 | NFR.Baseline.Testability.2 | E2E-test coverage - # of automated test cases from test rail to # of all test cases at a particular feature | Apr 11, 2024 COMPLIANT |
|
| |
11 | 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 | Apr 11, 2024 COMPLIANT |
|
| |
| Interoperability | NFR.MarcValidation.Interoperability.1 | The solution should provide the capability to support the ECS environment | Apr 11, 2024 COMPLIANT |
| |
| Reusability | NFR.MarcValidation.Reusability.1 | The solution should provide the capability to reuse core validation logic. | Apr 11, 2024 COMPLIANT |
| Implement core validation logic as a library providing the capability for other modules to use it with their own REST and DAO layers |
| Accessibility | NFR.MarcValidation.Accessibility.1 | Automated tests for WCAG 2.1 AA compliance | Apr 11, 2024 NOT VERIFIED |
|
|
| Usability | NFR.MarcValidation.Usability.1 | If it takes more than 2 seconds to check against MARC validation rules then show a message to users. | Apr 11, 2024 COMPLIANT |
|
|
LEGEND: Enumeration of possible statuses
COMPLIANT Compliance checked and confirmed
NOT VERIFIED Compliance not checked
NON COMPLIANT Compliance checked, and non-compliance found
Not Applicable Сompliance not required, requirement not applicable