When a new solution is being discussed, it’s easy to focus on all of the things it should do, what it should look like, and what technologies it should be based on. It’s very easy to get caught up in discussions with business resources about comprehensive feature sets and ways to present the information to customers. With a technical audience, it’s entertaining to squabble about the pros and cons of using one technology versus another to address the functional needs of a business problem.
When do discussions about disaster recovery, performance and scalability come into play? When should they? Why can’t I just say that the system shouldn’t fail, it should be fast, and it should be able to scale? The short answer is that this could be quite cost-prohibitive. The longer answers are below.
Let’s start with disaster recovery. I liken the conversation about disaster recovery to discussions about life insurance. To most people, it’s not fun to talk about what would happen if you die. Same goes for the brand new system you’re about to build. Disaster recovery is not a topic to be discussed AFTER the database gets corrupted or the application server CPU overheats. These are conversations that have to be had BEFORE the system is designed. Just as the functional requirements are documents, so should be these disaster recovery requirements. Based on different up-time needs and recovery efficiency, disaster recovery requirements could vary from making sure each server is backed up nightly to putting structure around a hot-backup on the other side of the country.
When it comes to talking about performance, the conversation tends to be easier; however, the proper documentation of performance requirements can be tough. How do you account for variations in network traffic? What if another process is running on your application server? The recommendation I have here is that you start by determining what an adequate response time looks like for the key functions in your new system. This needs to be balanced with the cost for delivering that kind of performance. Execute your performance tests in an environment that closely mirrors production. When it comes to documenting actual performance requirements, these can vary from a generic average response time per function to specific metrics around the key transactions of the system based on expected usage patterns throughout the day or during a specific time period (think concert ticket sales).
What about scalability? How do we expect the system to grow over the next several years? How many users do we expect initially? How many of them will be using the system concurrently? Even after having the answers to these questions (or best guesses), documenting requirements around scalability is difficult. I would recommend turning these into technical requirements around sustainable transaction throughput. Considering these requirements during the design phase allows you to build in the proper flexibility so the system can support the future anticipated growth.
Beyond these three different types of non-functional requirements, there may be many more that should be considered based on the system’s particular needs. The trick is to recognize early on in the initiation phase all the different non-functional aspects that are critical to the success of the system, documenting them, validating them, and ensuring they are written in a objective way.
