Network conditions have an obvious effect on applications, especially when a global audience
is considered. A fast application in North America (.25 - .50 ms response time) can become
slow in Asia Pacific (5-15 sec). Some of these challenges arise simply because of the amount
of content being shuttled across networks. Some delay can be minimized through caching
edge servers, better network backbones, and globally-distributed solutions.
Unexpected.Errors.Happen,.but.Who.Needs.to.Know?
Application developers are told to handle errors with grace, but the definition of ???grace???
often varies in meaning and context (Nielsen, 2003; Preece, 1994; Raskin, 2000). If an
application supports a very small audience, it might be preferred not to spend a lot of time
on exception handling. In most cases, though, applications are meant to benefit a larger
population and, often, a demanding user.
The most basic approach to handling errors is to employ custom error pages, so that at least
the error looks like it was intended to be read and responded to. This is the minimal amount
of effort required to keep up appearances.
Table 1. Sample non-functional requirements (NFR) for an enterprise application
Target Measured.
Pages:
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308