Non-functional requirements: Availability & Capacity

I've spent a bit of time writing on basic presentation, communication and innovation themes. Now I'm going to refocus and go into more detail on one of my earliest posts titled, What are requirements? SDLC? More specifically, I am going to expand my coverage of non-functional requirements and their implications.

Non-functional requirements govern characteristics of a system. Many non-functional requirements will have direct implications to a project in the form of cost implications, performance objectives and future growth potential.

Availability
Availability indicates when a system is operational as well as how reliable it is during operational periods.

1. Hours of operation - What are the hours that a given system will be available? What days will the system be operational? Not all systems operate on a 24/7 basis. Some internal facing systems may only be needed when there are people in place to operate them.
2. Reliability - During a system's hours of operation, what reliability (excluding planned outages) is needed? Reliability is usually measured as a percentage. The higher the number, the greater the cost. Many people ask for 99% reliability but do you actually need it? 37signals has a great post explaining this concept. The question to ask your clients is, "What level of reliability is justifiable from a business perspective?" Will the world end if your web site goes down unexpectedly for an hour? The answer will be different for different systems and companies.

Look at the picture below to see what are the allowable outages based on the level of reliability required.

Capacity
The ability to handle transactional volumes is a very important characteristic for a system. If you are building a high-volume e-commerce web site but you can only support 10 concurrent logins, you've got a major bottleneck. Here are a few considerations you will have to take into account:

• What are the different types of things (e.g., types of supported activities or transactions) that can happen?
• For each type of transaction, what volumes do you see on an hourly, daily, weekly, monthly etc... basis?
• What types of patterns exist for the transactions? Are volumes significantly higher during specific parts of the day (e.g., at lunch), week, month or year?
• What transaction volume growth are you expecting?
• Will additional systems make use of the services you are building? You may have taken into consideration your website's needs, but what happens when the point-of-sale systems start trying to use your services? Can you manage this additional volume?

Summary
Non-functional requirements such as availability and capacity can have substantial cost implications to a project. Almost everyone wants 24/7 hours of operation with 99.999% uptime and the ability to process thousands and thousands of transactions. However, does that meet the cost-benefit test?