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 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
|
||||
**[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