A significant term that comes up everywhere in the software world, yet is open for interpretation for everyone. The danger is when you and your client end up with a difference. It is critical to define what is meant by loose terms like good performance when software development is being discussed. Often performance starts with an all-inclusive definition, which can imply:
- response time
- startup time
- memory management
- scalability
- processor time
- fault-tolerance
- data integrity
- speed of input/output operations
- usability
- productivity
- functional behavior
Some of these seem to fit in, some don’t. The reason, perhaps, is that the performance of any piece of software has to be in context of its core requirements. Whether it is serving files, web pages, storing data, composing documents or building images, the all-inclusive definition of performance will vary.
That is why it is important to be as articulate as possible when performance is being discussed as part of the requirements. While the actual factors might vary, we can broadly classify the factors into three categories:
- speed
- efficiently using resources
- ease of use
Impact on performance specification can be huge on software development. A lot of times problems in software development are caused because of all-inclusive specification of performance. It is necessary to distinguish between functional responsibility of a software and its performance. This does not indicate significance or importance, performance is something that has to be considered right from architecture to the actual usage. But that you might have to focus on them separately.
Having said all this, the real performance can be tested only by the user. Called perceived performance, it is about the right or acceptable proportions of all factors. Like most of the engineering exercises, in software, the right balance is what serves the best. The aim of definiing performance for a project should be to identify the factors, but we have to be agile enough to vary the proportions of the factors to strike the right balance.
It is quite interesting and worth it to go through the individual factors but let us keep it for another time.

October 8th, 2007 at 3:37 pm
some in the list definitely do not qualify as NFRs.
Latency ,resilence and availability are quite often used in the NFRs of any software development project, more than anything else in the above list.
October 8th, 2007 at 5:43 pm
I really liked ur post, thanx for sharing. Keep writing. I discovered a good site for bloggers check out this http://www.blogadda.com, you can submit your blog there, you can get more auidence.
October 9th, 2007 at 1:48 pm
this lady is spamming about blogadda all over indian blogosphere…