Importance of Non Functional Requirements – Non Functional Requirements are to Performance Engineers what Functional Requirements are to Developers on a program. Non Functional Requirements are some of the most important (but not the only) and basic building blocks that go towards building a solid Performance Engineering strategy for your program. Miss out on one of the basic blocks and you’ll have challenges getting everyone on the program to speak the same language, forget achieving your targets. Before we dive deeper into article and look at Non Functional Requirements related challenges it makes sense to talk about the various focus areas for Non Functional Requirements so that all of us are on the same page. For purpose of this article i would like to define focus areas for Non Functional Requirements as follows:
- Disaster Recovery
- Maintainability & Operability
In my limited experience over the last decade and a half I’ve seen very few, infact just a handful of programs budget for a full time Performance Engineer all through the duration of the program. And the truth is, one of the reasons we were able to bake Performance Engineering into the program design was because of the fact that we happened to have good relationships with the individuals responsible for putting together the overall program design including the statement of work (SoW). So, don’t hope that you’ll be given a chance to make a difference, even good intentions are enough to bring about change. What one requires to bring about change is the ability to put your foot down, speak your mind and ask for the right thing to be done, albeit in a professional and bureaucratic manner. Don’t be a rude cowboy, you won’t get much traction.
What should my focus be – Systems being designed today are complex interconnected set of applications, partially hosted within the organization datacenters connecting to SaaS based services hosted all over the internet. In a situation like this where you have complex application architectures connecting to service buses that then connect to 3rd party SaaS based application suites hosted within a 3rd party data center the question that generally tends to come up is, “How can we be responsible for defining Non Functional Requirements and delivering End to End Client Experience that include transactions that traverse through infrastructure or environments we have no control over”. This is quite a common occurrence and I will be truly surprised if you haven’t encountered one of these on your own programs.
It’s easy to shy away from taking responsibility for the End to End Transactional response times by drawing a boundary across the system in such a manner that the Non Functional Requirements do not include Response Times targets or throughput targets for the 3rd Party Service provider. I agree that it’s not easy to take responsibility for Performance of any system if you do not have control of the environment of infrastructure over which the transaction traverses.
How can i avoid drawing the wrong system boundaries – In situations like this I would urge you to ask yourself the following questions:
- What are the entry and exit points for the end customers using the application
- What really matters to the end customers using the application
- What are the factors that will influence the End User Experience as seen by the end customer and how many of those variables are currently within your control
- What are the factors that will influence the End User Experience as seen by the end customer and how many of those variables are currently outside of your control
Drawing system boundaries and making the program take responsibility for End User experience for transactions that flow across boundaries into 3rd party SaaS providers environments is tough. You have to be really sure of what you are trying to achieve, what are the factors within your control, what are the factors out of your control and how you can productively steer the conversation working out the relevant agreements with your client and the 3rd party service provider.
The question i always ask myself is, “What is the end customer going to expect when he/she uses this application”. An answer to that question helps me better picture what should be the nature of system boundaries for the Non Functional Requirements i put in place.
Negotiation is a black art – I don’t claim to be a negotiation superstar and i would generally leave that to the legal and procurement guys within the client organization. However as the Lead Performance Engineer or Lead Performance Architect on the program it is your responsibility to work with the client and ensure that the client has thought through the ramifications of having or not having a agreed set of Service Level Agreements (SLA’s) with the 3rd Party SaaS based service provider. Without strict SLA’s with your SaaS based service provider you will have challenges defining the relevant system boundaries and taking responsibility for Non Functional Requirements across the entire transaction path which is essential for you to deliver an application that meets the document and agreed Non Functional Requirements. Few SaaS based vendors are willing to consider rigid SLA’s especially since they can’t be seen responsible for the internet links that connect your datacenters to theirs over the open public internet. SaaS based vendors might provide SLA’s but when you read into your dotted line you will figure out that they do not hold themselves responsible for performance of their application outside of their data centers, which is understandable and completely reasonable. Make sure you understand the implications of these SLA’s and agreements before you push for any changes.
Closing notes – Non Functional Requirements are some of the most important building blocks for a solid Performance Engineering strategy. Without a good Performance engineering strategy and clear Non Functional Requirements you will end up in a situation where every team on the program has their own view of what Performance should look like. It’s also not easy taking on responsibility for delivering performance for an application that traverses system boundaries into 3rd party SaaS based providers data centers which are out of your control. It’s a tough one, there is no easy way out and i don’t suggest at any point that any of this is a cake walk. But as the Performance Architect on the program it’s your responsibility to ensure that the End User Experience drives your definition of Non Functional Requirements ensuring you draw the system boundaries accordingly.
As always, send us your thoughts, inputs and comments at trevor at practical performance analyst dot com.