Technical Documentation Standards · DOC-03

This should be documented in the form of one or more architecture diagrams.

ADRs can be included in the main project wiki or in the same repo as the source code (and linked to from the main wiki).

Possible hosting locations include:

• Audacia CSP hosted
• Client hosted
• Third-party hosted (the third-party must be specified)

Some examples of access that should be documented are:

• Guest accounts in an external Azure tenant
• Separate client-provided accounts
• Any specific access requirements, like a VPN or white-listed IP address

NOTE This information must be recorded in Olympus.

Examples of non-functional requirements are:

• Performance and response times
• Accessibility
• Device testing requirements (these should be captured in the Test Strategy)
• Logging and observability

The kind of processes that should be documented include:

• CI/CD pipelines
• Health checks
• Release windows, i.e. any days/times agreed by the client
• Manual processes (where applicable)
• Rollback procedure

This should include the overall strategy, the reasoning behind it, and any specific details such as naming conventions, e.g. release/.

The following items must be included:

• Agreed Recovery Time Objective (RTO) and Recovery Point Objective (RPO), or if none has been agreed a statement to this effect together with a reference to when this decision was made
• Details of any processes to follow beyond restoring data to a known point, e.g. any manual failover tasks or fallback to paper-based processes
• Details of what backups are taken, at what frequency, to what location, and who owns them

For example, Postman collections or JMeter scripts.

NOTE This is only applicable if feature switches are actually in use.

This should be some signposting to the relevant resources, e.g. an automated test repo and/or Azure DevOps test plan.

A ‘state of play’ of the automated tests must be documented, covering things like test coverage, which system areas have been targeted and where there are known gaps.

Include information that will be useful for anyone triaging or debugging an issue, such as where logs are located in each environment.