UXPROD-4559 NFR Scorecard

1

Availability

NFR.Baseline.Availability.1

Modules are designed and implemented following the Stateless principle

Feb 13, 2024 COMPLIANT

2

NFR.Baseline.Availability.2

Load/performance testing must be conducted for at least 2 instances

Feb 13, 2024 NOT VERIFIED

We follow this requirement by design, but it makes sense to check the implementation

OkApi-based timer used; Kafka events processing

ACTION ITEM Conduct performance testing

3

Manageability

NFR.Baseline.Manageability.1

Application logs are collected in a unified form and location

Feb 13, 2024 COMPLIANT

new code follows this

4

NFR.Baseline.Manageability.2

All custom configuration values are placed in the settings, not in the program code

There are few configurations. Access parameters to the database or Kafka - the standard approach is used

 NOTE: a feature flag - should be a part of mod-tlr (TBD...)

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

6

Security

NFR.Baseline.Security.1

Tenant data must be isolated from other tenants

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)

8

NFR.Baseline.Security.3

No sensitive information in logs (logins, passwords, API keys)

9

Testability

NFR.Baseline.Testability.1

Unit-test coverage for new code created/changed during the implementation of the feature >= 80%

10

NFR.Baseline.Testability.2

E2E-test coverage - # of automated test cases from test rail to # of all test cases at a particular feature

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