Sample NFRs and deployment plan

It’s never too early to start thinking about deployment.

In fact, the way you deploy and support an application should be deeply embedded in your development process to the point where you don’t even have to think about how you deploy it. Many large organisations working on big, monolithic codebases feel a million years away from achieving continuous deployment but by working towards this goal - even if it’s never going to be achieved - is a great way to make your deployments and live support easier, more predictable and less stressful.

The tendency is for a gulf to exist between development and operational support. As someone who cut their teeth on a one-week-on, two-weeks-off support regime, I think this is a shame. There’s a huge amount to be learnt about writing good quality code when you’re trying to debug it in production at 2am, and there’s nowhere to hide when it comes to knowing tools, systems and the business.

There’s also a lot to be learnt from being the person who flicks the switch on a deployment to production. It’s not unusual for deployments (especially for ecommerce sites) to take place in the middle of the night, and those are the times when you really don’t want to be relying on everyone being alert to make things go smoothly. Being well prepared and having everything easily to hand is essential.

To help start the conversation, here is my template NFRs and deployment plan.

Deployment Plan

NOTE: All system-oriented requirements (such as those needed for acceptance into service) should have been captured in the NFRs.

Stakeholders identified

Pre-live business success criteria

• Have we met the requirements for a minimum viable product? (Scope)
• Has the product been adequately tested/QA’d? (Quality)
• Has the business signed off on deployment/change windows (Time)

Pre-live systems success criteria

• NFRs have been met
• Acceptance into Service requirements have been incorporated into NFRs
• Appropriate documentation is in place and accessible to everyone who needs it
• SLAs and support arrangements are in place and have been agreed
• Network and infrastructure requirements have been met

Data cutover/migration plan

• What data needs to be replicated into the new system?
• What data needs to be kept in sync between the two systems during cutover?
• What data scripts need to be run, and on what triggers, by whom?
• What are the data rollback plans?
• What are the post-project data archiving plans?

System cutover/migration plan

• How are users/customers going to be cut over from one system to another?
• What are the success criteria for each cutover stage?
• What checks are going to be performed, how, and by whom?
• Have appropriate cutover windows been identified, if appropriate?
• For out-of-hours deployments, has overtime been agreed, does everyone have access to the relevant buildings, have communication routes been put in place, has the building management team been notified, what arrangements for food and drink need to be made? (As an aside: your deployments should never be so big and risky as to need all this)
• Rollback plan for each stage.
• What are the post-project systems tidy-up plans?

Code management plan

• What code branching/tagging activities need to happen? Who is responsible?

Communications plan

• What distribution lists are needed and who needs to be on each list?
• Who is responsible for sending emails/other communications?
• What are the stagegates/triggers for communications?

Support and escalation

• What are the support routes during migration/cutover?
• What are the escalation routes in case of problems?

Non-Functional Requirements (NFRs)

Note: this is by no means an exhaustive list!

Performance and volume

• Number of page requests per hour - average (mode)
• Number of page requests per hour - maximum
• Number of orders placed per hour - average (mode)
• Number of orders placed per hour - maximum
• Number of concurrent order sessions - average (mode)
• Number of concurrent order sessions - maximum
• Order size (number of items) - average (mode)
• Order size (number of items) - 95th centile
• Order size (value of items) - average (mode)
• Order size (value of items) - 95th centile
• Homepage response time - average
• Homepage response time - 95th centile
• Product page response time - average
• Product page response time - 95th centile
• CDN requirements
• Horizontal scalability (add more servers)
• Vertical scalability (make servers bigger)
• Database scalability

Uptime and support

• Define "out-of-hours" times (evenings, nights, weekends, bank holidays)
• Define first line support
• Define second line support
• Define third line support
• Out of hours channels and response time to outage
• In-hours channels and response time to outage
• Log file access
• Application monitoring, alerting and analysis
• Network monitoring, alerting and analysis
• Acceptable unplanned outage time, hours per month
• Acceptable planned outage time (including deployments), hours per month
• System restore
• Dual-site failover
• Load balancing, DDoS, and network requirements
• 3rd Party dependencies and backups in case of failure
• Frequency of deployment
• Disaster recovery plan

Platform targeting

• Target platforms/browsers
• Target screen sizes/aspect ratios
• Target connection speeds
• Text size changes, colour contrast and screen reader/tab order

Security and Legal

• PCI compliance
• Any other legal compliance/certification requirements?
• Password/other encryption
• User authentication
• User authorisation
• Data protection/privacy
• Ethical hack test
• Software licensing
• Copyright/content licensing
• Data audit requirements
• Data retention/archiving policy