Why am i writing this article: Working on projects at different client locations, it’s not un-usual for me to find that we tend to want to re-inventing the wheel time and again. Over the last decade I have had the opportunity to work at some of the largest organizations around the world and the one sad thing (can assure you that there are numerous good things as well) that i keep encountering time and again is the fact that most programs I have worked on have no Non Functional Requirements or such poorly defined Non Functional Requirements that it makes validating overall system performance or end user experience an uphill task. Frankly if there are no SLA’s or Non Functional Requirements to build against then how do you validate the quality of what’s beign delivered. Unfortunately most customers, Technical Architects, Program Managers, etc. view Performance from their rose tinted glasses and assume that having an experienced Performance Tester on board at the end of build phase is enough to address their performance and capacity woes. Every time i think about this and visualize the amount of time, energy and resources that will be spent by organizations around the world trying to retrofit performance into the application at the end of the program product my stomach cringes and i feel despair setting in.

But at Practical Performance Analyst we are hopeful that things will get better and tomorrow will be brighter.At Practical Performance Analyst we are about making tomorrow a brighter day than today and giving people like yourself the insight gained from years of experience designing/building/delivering complex systems for customers around the world. All of this seems like rocket science but the fact is that it isnt. All it requires is that you ask the right questions and determine the right answers so that the architects design a scalable solution, the army of developers write code supporting the architecture to scale and meet the documented Non Functional Requirements and that the performance guys are able to tune, optimize, test and deliver a scalable system. Sounds easy isn’t it? Well, by the end of this article i hope you to realize that it really is as easy as i make it sound.

This article was originally published on 2012-18-10 at the original Practical Performance Analyst website.

What are Non Functional Requirements: Functional requirements for an application are generally determined by the Business Analyst (BA) on a program working closely with their counterparts from Business. Functional requirements as the name suggests are desired functionality that the business would like build, have tested and delivered by the given program or project. While it is true that most programs focus on delivering applications with Functional Requirements or enhancements that are aimed at adding or creating additional functionality, programs (pieces or units of work) can also be designed with the sole objective of addressing the Non Functional Requirements for a given application or application stack. However its quite rare that programs are designed to meet only Non Functional Requriements or improve existing ones. Most programs are designed to deliver Functional enhancements while having a set of Non Functional Requirements that need to be met. Non Functional Requirements for a system could be potentially categorized as follows:

• Performance NFRs: The application should be able to process 100 Pages/Sec for 1000 Concurrent Users submitting 10 Orders/Sec and with Page Level Response times < 5s for Simple pages, <8s for Medium Complex pages and <10s for Very Complex pages.
• Infrastructure Utilization NFRs: Infrastructure Utilization for Peak workload (as documented in the Performance NFR’s) should not exceed 75% utilization for CPU and 90% utilization for Memory.
• Network Utilization NFRs: Link Utilization for Peak Workload (as documented in the Performance NFR’s) should not exceed 90% Utilization. Application Bandwidth requirements should be presented as part of the Performance Models and included in the over program infrastructure cost estimates.
• Availability or Reliability NFR’s: The system will be built for an availability of  99.999% (31.5 seconds of Downtime Per Year,  2.59 seconds of Downtime Per Month, 0.605 seconds of Downtime Per Week)
• Fail-over NFRs: The system will be designed to fail-over seamlessly from the Production site to the Disaster Recovery (DR) site in event of a catastrophic failure. All sessions will be maintained and would be expected to failover along with the primary site.

There are numerous other categories of Non Functional Requirements and i don’t intend to cover every conceivable scenario but rather provide a flavour of what Non Functional Requirements should look like while documenting a few examples.

Why Are Non Functional Requirements Important: This discussion is specifically focussed on Performance NFRs and thats what ill be referring to throughout the rest of this article. Non Functional Requirements are essential to every program since they define the performance boundaries for the application. Non Functional Requirements determine the technical specifications of the product that will be delivered and help communicate the scalability characteristics of the application being designed and delivered. Non Functional Requirements offer key design specifications which support the architectural decisions made and in many ways can be seen as buiilding blocks on which the system scalability depends. A good understanding and an agreement on the Non Functional Requirements ensures that the Application Architects, Infrastructure Architects, Developers, Testers, Support teams and most importantly Business are clear about the scalability constraints that will be built into the application and underlying infrastructure platform. Non Functional Requirements also quantify what the investment is going to deliver and how far into the future can the application be expected to go in terms of meeting growth in end user workload. Poorly defined NFRs are un-fortunately almost as bad as not having any NFRs defined at all since poorly defined NFRs are generally open to interpretation in different ways leading to ambiguity and possibly litigation between different parties involved. And seriously, i am not joking when i refer to poorly defined NFR’s being open to interpretation of the reader!!!!

Examples of Non Functional Requirements: Ill repeat examples of Non Functional Requirements as provided above and dive into a bit more detail.

“The application should be able to process 100 Pages/Sec for 1000 Concurrent Users submitting 10 Orders/Sec and with Page Level Response times < 5s for Simple pages, <8s for Medium Complex pages and <10s for Very Complex pages.”

The above Non Functional Requirement is designed to communicate the requirement that the application being built is being designed to meet the following specifications:

• 100 Pages/Sec
• 1000 Concurrent Users
• 10 Orders/Sec
• Page Level Response Times – < 5s for Simple pages, <8s for Medium Complex pages and <10s for Very Complex pages.

“The Reporting Batch should process 100,000 records in a span of 10 minutes under 75% utilization with no other job running concurrently on the server”.

The above Non Functional Requirement is a specific Batch Job SLA and requires that the batch job be design to complete processing for 100,000 records in under 10mins utilizing not more than 75% CPU while no other job is running on the box.

“Infrastructure Utilization for Peak workload (as documented in the Performance NFR’s) should not exceed 75% utilization for CPU and 90% utilization for Memory.”

The above Non Functional Requirements are designed to communicate the need for Infrastructure Capacity to be sized such that Infrastructure CPU Utilization across the boxes shouldnt cross 75% utilization and Memory Utilization should cross 90% utilization. Non Functional Requirements are of different types, will vary from application to application and from implementation to implementation. The Non Functional Requirements documented above are for OLTP (Online Transaction Processes) applications however Batch, Messaging and Workflow based applications will have very Non Functional Requirements on similar lines.

Traditional approach to designing and managing Non Functional Requirements: The traditional approach to managing Non Functional Requirements is to pretty much do nothing or coming up with very poorly designed and documented Non Functional Requirements. The challenge of such an approach is that Non Functional Requirements of the application or platform being delivered are open to interpretation any which way by all the parties involved and you would agree that un-fortunately this is the best way to enter into litigation with someone you are doing business with. Managing Non Functional Requirements is an art, its an ongoing process that requires someone with the breadth of understanding in performance, application design and infrastructure design to work with the business and the project teams towards defining Non Functional Requirements that make sense and which can be met in the stipulated time frame using the tools, methodologies, practices, platforms and resources at hand. The key is designing Non Functional Requirements that meet the business requirements while delivering the required scalability to meet growth in user workload.

What are the prerequisites for documenting Non Functional Requirements: The prerequisites for documenting Non Functional Requirements are:

• Obtain a good understanding of the application architecture
• Obtain a good understanding of the business requirements
• Obtain a good understanding of the existing customer workload in production
• Obtain a good understanding of the existing data volumes in production
• Obtain a good understanding of the expected customer growth and validate this with data from the past
• Obtain a good understanding of the business strategy and the expected impact of that strategy on growth of user workload and data volumes

Documenting Non Functional Requirements is made easy if you have an inquisitive individual who is keen on poking around to unearth the facts and learn more about what the business do today. Since knowing what happens in production today combined with an insight into expected business growth will give you a strong understanding of the Non Functional Requirements that are acceptable to both Business and IT.

Who should have the Responsibility for documenting Non Functional Requirements: The jury is still out on this one but i’ll take the the liberty of presenting my thoughts on this one.

• Architecture taking ownership
• Performance Engineering taking ownership
• Developers taking ownership
• Operations taking ownership

On a very large number of programs i have noted that the ownership of the Non Functional Requirements lies with Architecture. However my recommendation is that while the folks from Architecture should play an important role in providing guidance it should be the Performance Engineering team taking ownership and driving the Business, Architecture teams, Design teams, Operational Support teams for consensus on what the actual Non Functional Requirements should be.

The ideal situation of course is that a Performance Engineering team exists and that team is given ownership of Non Functional Requirements across the program. The last two (Developers and Operations) taking ownership are least recommended since these teams  aren’t best placed in terms of visibility or capability to drive Non Functional Requirements for the given application platform. Ownership of Non Functional Requirements is a key ingredient for success on any program. Having one team owning, creating, driving, maintaining, updating and ensuring consensus across teams, is key to success from a Performance Engineering standpoint.

Getting consensus and sign off on your Non Functional Requirements: Nailing down Non Functional Requirements for the program is a great achievement in itself. However if Architecture has their own view of the NFRs, Business has their own view of the NFRs, Operations have their own view and Developers have their own view we won’t get much done and the effort would be in vain. Having the technical prowess to determine and document the Non Functional Requirements is absolutely essential however what is more essential is the ability to bring all the teams to the table and negotiate the Non Functional Requirements and obtain consensus. If Performance Engineering was easy everyone would be doing it…:)

At What Point in the SDLC should Non Functional Requirements be nailed down: This is a really important question and also one of common sense. A lot of programs i have worked with take the liberty of ignoring Non Functional Requirements and Performance Engineering in general until things start going pear shaped later in the program. My recommendation on this one is to ensure that work around Non Functional Requirements are kicked off at the same time that the Business Analysts have begun work on defining the Functional Requirements. I have been told numerous times over that having Performance Engineering resources early in the Software Development Lifecycle is a waste of time and effort and i try my best to convince them that every time we have had a Performance Engineering resource on a program nail down Non Functional Requirements before design we have had the opportunity to work with the Application Architects, Infrastructure Architects, Development teams and Operation teams on designing an application that meets the documented Non Functional Requirements. Start early, do the hard work, collect all the relevant data, document the findings and obtain consensus early on. Once you set the tone and establish the goals it becomes a lot easier for the other key functional elements to fall in place.

Modeling Performance using Non Functional Requirements early in the SDLC: One of the other benefits of documenting your Non Functional Requirements early on in the Software Development Life Cycle is that it gives the Performance Engineering team the ability to model Performance of the application and validate the application performance for different combinations of infrastructure using a combination of Analytical and Simulation Models. While i won’t go into details here, seasoned Performance Engineers would understand that with knowledge of Non Functional Requirements and Infrastructure Capacity assumptions one can use a combination of different modelling techniques to validate performance and scalability limitations. Thus giving the design teams an opportunity to make drastic changes to the application and infrastructure design early on without impacting the program.

Keeping your Non Functional Requirements updated and current: Having detailed Non Functional Requirements is great, validating them early on using modeling techniques and then later in the development lifecycle using Performance Testing is the best way of ensuring you meet your targets. However, Non Functional Requirements like a lot of other requirements change especially when working on very large programs that span 8-12+ months. Thus one has to keep in touch with the documented Non Functional Requirements and work closely with Business, IT and Architecture to ensure that the documented Non Functional Requirements are relevant and useful.

Hope you have enjoyed this piece here at Practical Performance Analyst. Drop us a note with your comments, inputs and feedback at trevor at practical performance analyst dot com. If you are interested in learning the fundamentals of Systems Performance Engineering please head over to the SPE Fundamentals section to learn more about the fundamental equations and strengthen your understanding of the various SPE related concepts.

Drop us a note if you have any questions, comments or input.