UXPROD-4305 NFR Scorecard
Please, refer to NFR Scorecard practice for detailed information
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 | NOT VERIFIED | Check that the feature is working similarly with 1 or more instances | |
2 | NFR.Baseline.Availability.2 | Load/performance testing must be conducted for at least 2 instances | NOT VERIFIED | Will be checked by NFR.AuthorityStorage.Performance.1 | ||
3 | Manageability | NFR.Baseline.Manageability.1 | Application logs are collected in a unified form and location | COMPLIANT | COMPLIANT | |
4 | NFR.Baseline.Manageability.2 | All custom configuration values are placed in the settings, not in the program code | COMPLIANT | 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 | COMPLIANT | The current performance of deleting is not good (~1 sec in UI), the feature implementation should be improved | |
NFR.AuthorityStorage.Performance.1 | The system can sustain the following load:
| NOT VERIFIED | Load test: Check how many records can be loaded in a single request. And set limits Dependency: the amount of exported IDs should be supported by the export authorities (Firebird) | |||
NFR.AuthorityStorage.Performance.2 | The database size should not affect the performance of a single operation: ~100K deleted records in a year. | NOT VERIFIED | Leverage existing data-import profiles.
The question: How to properly prepare data TODO: Kalibek Turgumbayev Create a ticket to PTF - DONE | |||
6 | Security | NFR.Baseline.Security.1 | Tenant data must be isolated from other tenants | COMPLIANT | TODO: Kalibek Turgumbayev : Authorities are shared across ECS and for ECS the compliance is either not applicable or non-compliant. - DONE The data is isolated and support for ECS environment is implemented separately in the ticket - MDEXP-681Getting issue details... STATUS | |
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 | COMPLIANT | No integration and no API keys or authentication tokens, hence no secrets. See sonar scan results: https://sonarcloud.io/project/overview?id=org.folio%3Amod-entities-links | |
8 | NFR.Baseline.Security.3 | No sensitive information in logs (logins, passwords, API keys) | COMPLIANT | COMPLIANT | ||
9 | Testability | NFR.Baseline.Testability.1 | Unit-test coverage for new code created/changed during the implementation of the feature >= 80% | COMPLIANT | COMPLIANT | https://sonarcloud.io/project/overview?id=org.folio%3Amod-entities-links |
10 | NFR.Baseline.Testability.2 | E2E-test coverage - # of automated test cases from test rail to # of all test cases at a particular feature | NOT APPLICABLE | NOT APPLICABLE | No UI for the feature. No need for E2E tests in this case | |
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 | COMPLIANT | COMPLIANT | TODO: Pavlo Smahin : Create karate-test tickets. - DONE |