Eleanor McHugh wrote:
> On 30 Mar 2008, at 07:42, mutahhir hayat wrote:
>>> Yes ... as you state below, if a project is defined by requirements,
>>> performance requirements should be specified. They fall under the
>>> general heading of usability, and there are (and have been for decades)
>>> rather well known rules of thumb.
>>>
>>
>> Are you saying that there are projects that have no requirements? :) I'm
>> sure that you don't mean that, so please elaborate.
> 
> Many projects have requirements which are only loosely identified at the 
> time of inception, but one that tends to be there from the very 
> beginning is "should perform acceptably for users". Ignore that 
> requirement at your peril :)

Actually, there are implicit performance requirements based on decades 
of usability theory. The "prime directive", as it were, is this:

1. Define "response time" as the time it takes from the moment that a 
user sends a request to the moment when the system has returned its 
response. There are application-dependent definitions as to when the 
response is "complete", but these are usually obvious from other UI factors.

2. The ideal case is that the response time is under one second! 
Anything over 10 seconds requires that the application notify the user 
that it is busy. Between 1 and 10 seconds is kind of a "gray area", but 
in general, times over 1 second interrupt a user's flow process and 
should be avoided.

3. Users of a business application need faster response times than what 
we consumers typically "tolerate" from web applications. For example, go 
to your on-line credit card payment center and time how long it takes 
from when you hit the "submit" button to when you get your confirmation 
number back. It might be 10 seconds -- in the "good old days" I remember 
seeing times of about a minute. Times like that are "tolerable" for 
someone who makes a payment once a month. But someone in a business 
posting data will need that response in under a second.