Skip to end of banner
Go to start of banner

UXPROD-1845 NFR Scorecard

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Please, refer to NFR Scorecard practice for detailed information

Status

NEW

Architect

Raman Auramau 

Team Lead

Serhii_Nosko 

Scrum Master

Mikita Siadykh 

Product Owner

Dennis Bridges / Joseph Reimers 

Prod Ticket

UXPROD-1845 - Getting issue details... STATUS

Arch Ticket

ARCH-140 - Getting issue details... STATUS

Tech Design<link to the related documentation>

Quality Attribute

NFR ID

Non-Functional Requirement

Preliminary Analysis (Before feature started)- Date and Status

Final Analysis (After feature completed) - Date and StatusNotes and Comments
1

Availability

NFR.Baseline.Availability.1

Modules are designed and implemented following the Stateless principle

COMPLIANT


  • A job triggering dates/status and all the data are in mod-orders-storage. The job can be invoked by a scheduler but this is managed by an RMB scheduler which can avoid 2 jobs running in parallel
  • Status change events are published to mod-audit via Kafka
2

NFR.Baseline.Availability.2

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

NOT VERIFIED


  • ACTION ITEM Manually set up 2 instances of mod-orders-storage on the dev rancher and confirm that there are no issues with concurrent jobs
3

Manageability

NFR.Baseline.Manageability.1

Application logs are collected in a unified form and location

  NOT VERIFIED


  • ACTION ITEM Make sure the information regarding job execution (at least, start time, duration, a number of processed pieces) is available in the logs
4

NFR.Baseline.Manageability.2

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

   NOT VERIFIED


  • ACTION ITEM Make sure that the job execution start time is configurable via application properties
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 APPLICABLE


  • Since the job runs once per day there are no specific requirements or expectations from the performance perspective
6

Security

NFR.Baseline.Security.1

Tenant data must be isolated from other tenants

NOT VERIFIED


  • ACTION ITEM Let's use rancher env with 3 tenants of ECS and make sure this job runs as expected on each tenant
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)

NOT APPLICABLE


  • No secrets or sensitive info
8

NFR.Baseline.Security.3

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

  NOT APPLICABLE


  • No secrets or sensitive info
9

Testability

NFR.Baseline.Testability.1

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

NOT VERIFIED


  • This is a part of Quality Gates
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 VERIFIED


  • Will be handled by AQA team based on the tests provided by dev team manual QAs (question)
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

 NOT VERIFIED


  • ACTION ITEM A dedicated story to prepare Karate tests

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

  • No labels