NFR vs FR What’s the Difference
So this morning I was asked to review a whole bunch of non functional requirements for a project delivering a brand new system. As an experienced Service Manager I was specifically asked to review the NFRs that related to Operations Architecture and I was struck by how many of these non functional requirements or NFR were actually functional requirements.
Functional Requirements vs Non-Functional
So the classic description is that the Functional Requirements describe what the system will do and non functional requirements describe how it should do it. But how does that relate to operations and our role as Service Managers to monitor and mange the system?
Well, generally speaking the NFRs should describe the availability and performance targets for the service. Is it to be available 24 x 7 or Mon-Fri 9am to 5pm? What’s the target time for a static web page refresh vs a dynamic generated page of content?
For all new services, I am looking for NFRs in the following categories
- Availability – not only the service hours that the service is required to be available but also the target SLA for uptime expressed either as the number of hours downtime allowed or a % availability.
- Performance – the speed of response expected and threshold at which a service is deemed to no longer be available (x% of static pages respond in y seconds)
- Maintainability – The ease with which the service can be worked on and the impact of maintenance on the performance and availability of the the service (e.g. should it be possible to replace, upgrade or patch individual nodes with no impact on availability and no more than x% uplift on response times). You might also want to have agreed maintenance slots that are reflected in the availability calculation
- Serviceability – How easily available is support, what can be serviced using in-house teams vs specialist vendors etc. If you are already outsourced to an MSP or have a SIAM model does your provider have skills to manage this type of technology.
- Scalability – how easily the service can scale either horizontally or vertically and the impact on performance and availability of the scaling (e.g. elastic load balancing and auto-scaling vs taking the service down to add memory etc)
- Usability – a measure of how intuitive the service is to use and the amount of effort expressed as time or cost to train new users. You might also want to agree language packs supported, browser and device type compatibility and any accessibility criteria (DDA etc)
Depending on where it sits in your organisation, you might also want to see non functional requirements (NFR) for Disaster Recovery and Security.
Design for Service
The non functional requirements should all influence the overall architectural design of the new service and should also be used to feed your test strategy and test plan to ensure that they can be met from the get-go.
Systems must be stress tested with anticipated future volumes and also tested for co-existence with other processes such as running backups or scheduled batch
Non-Functional Requirement and Service Architecture
Just as the architectural design needs to reflect the NFRs, so does your Service Architecture (a term that I will post more on later). You need to ensure that you are able to monitor and report against the desired requirements for availability, speed of response, fault containment etc