Update 'Tech to do list'
parent
734e460e53
commit
8c676934c3
|
@ -106,6 +106,71 @@ See the `Extentions` section [here](https://unite.openworlds.info/Open-Media-Net
|
||||||
|
|
||||||
## NFR (Non Functional Requirments)
|
## NFR (Non Functional Requirments)
|
||||||
|
|
||||||
|
NFR (Non Functional Requirements)
|
||||||
|
|
||||||
|
###Development Framework
|
||||||
|
Use a modem cross platform framework
|
||||||
|
Deployment support for AWS Lambda, Azure Functions, and Google Cloud Functions, and others
|
||||||
|
Framework examples https://www.pulumi.com/ and https://www.serverless.com/
|
||||||
|
Simple deployments and update
|
||||||
|
Infrastructure as code pattern
|
||||||
|
###Development
|
||||||
|
GIT Version control
|
||||||
|
GIT Flow with feature branches
|
||||||
|
Code review at check in
|
||||||
|
All business logic and algorithms must be documented
|
||||||
|
High level of automated testing coverage
|
||||||
|
Developers are able to run their own deve
|
||||||
|
###Release notes
|
||||||
|
Change sign off for production
|
||||||
|
Zero downtime updates (using green blue pattern)
|
||||||
|
###Quality Control
|
||||||
|
Dedicated QA staff
|
||||||
|
Automated and manual testing
|
||||||
|
Pre release testing
|
||||||
|
Regression testing
|
||||||
|
Active monitoring and issue alerting
|
||||||
|
Dashboard to clearly see the current performance
|
||||||
|
Dashboard to clearly see the current performance
|
||||||
|
###Performance
|
||||||
|
High performance that scales up and down
|
||||||
|
Paged data access. The UI only loads data needed to show on the current page
|
||||||
|
Scaling based on partner and customer usage load
|
||||||
|
Processing times for imports and exports
|
||||||
|
###Reliability
|
||||||
|
2 physical live (active/active) locations for all production infrastructure and data storage
|
||||||
|
Security
|
||||||
|
Encryption of all data during transmission
|
||||||
|
Encryption of all data at rest (files and Databases)
|
||||||
|
Use a key management system so the keys are not exposed to ops and devs
|
||||||
|
Password requirements - length, special characters, expiry, recycling policies, 2FA
|
||||||
|
Login / Access levels
|
||||||
|
User session / Inactivity management - Durations, actions
|
||||||
|
Audit table of all user driver changes so it is clear who did what
|
||||||
|
Capacity
|
||||||
|
High transactions per second
|
||||||
|
Storage - how much data does the system need to store
|
||||||
|
Year-on-year growth requirements
|
||||||
|
Integrity
|
||||||
|
Bad data trapping - data imports, flag and continue, stop the import policies
|
||||||
|
Filtering test data from production
|
||||||
|
Localization
|
||||||
|
Support multiple currencies
|
||||||
|
Support multiple tax systems
|
||||||
|
Support multiple delivery systems
|
||||||
|
TLDs eg .de .fr
|
||||||
|
Directory based eg /pt /it
|
||||||
|
Disaster planning
|
||||||
|
Recovery plan for systems and staff
|
||||||
|
Backup of code and data - Frequency
|
||||||
|
Process of restoring data and backups
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### Requirements
|
### Requirements
|
||||||
**[Can we list what the key behaviours of the system should be. In part I want to be certain that a wiki is the most suitable candidate - the initial list here was taken from the end of the previous version of this document]**
|
**[Can we list what the key behaviours of the system should be. In part I want to be certain that a wiki is the most suitable candidate - the initial list here was taken from the end of the previous version of this document]**
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue