UXPROD-4125/UXPROD-4126 NFR Scorecard
Status | NEW |
---|---|
Date-time | Jul 18, 2024 |
Dev Team | Spitfire |
Architect | @Kalibek Turgumbayev |
Product Owner | @Khalilah Gambrell |
Scrum Master | @Natalia Zaitseva |
Team Lead | @Pavlo Smahin |
Prod Ticket | UXPROD-4125: Inventory app | Audit log/Change tracker v1Open UXPROD-4126: MARC authority app | Audit log/Change tracker v1Open |
Arch Ticket | <link to Jira ticket> |
Tech Design | |
Release | Sunflower (R1 2025) |
| 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 |
|
|
|
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 |
|
|
|
4 | NFR.Baseline.Manageability.2 | All custom configuration values are placed in the settings, not in the program code |
|
|
| |
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 |
|
|
| |
12 | Scalability | NFR.InvAudit.Scalability.1 | Audit log supports up to 20 years of history data |
|
|
|
13 | Configurability | NFR.InvAudit.Configurability.1 | Versioning/Audit can be disabled through configuration |
|
|
|
14 | NFR.InvAudit.Configurability.2 | Anonymization of versioning/audit events can be enabled through configuration |
|
|
| |
15 | Data consistency | NFR.InvAudit.Consistency.1 | Opt1. Fail in the persistence of audit events should not block the persistence of instance/authority/etc Opt2. Fail in the persistence of audit events prevents business operations (atomicity of business operations) |
|
|
|
16 | NFR.InvAudit.Consistency.2 | The solution supports the existing optimistic locking mechanism |
|
|
|
LEGEND: Enumeration of possible statuses Compliance checked and confirmed COMPLIANT Compliance not checked NOT VERIFIED Compliance checked, and non-compliance found NON COMPLIANT Сompliance not required, requirement not applicable NOT VERIFIED |
---|