9.1 Response Time Requirement Pattern


9.1 Response Time Requirement Pattern

Basic Details

Related patterns:

None

Anticipated frequency:

Between zero and three requirements, rarely more

Pattern classifications:

Pervasive: Maybe

Applicability

Use the response time requirement pattern to specify how much time the system may take to respond to a request. It is typically used where the time an operation takes is of interest to a person (normally a user) or another system.

Do not use the response time requirement pattern just for the sake of it. If a particular response time isn't vital, don't worry about it.

Discussion

Response time is the length of time between a request being submitted at a particular place to a system and a response being perceived at the same place. It is most popularly applied to user response time, which is the length of time between a user submitting a request (hitting the button) and the response being displayed on their screen. But this pattern can be used for other operations, for instance physical processes (such as the time to manufacture or physically deliver something) and processes involving multiple people (for example, if a step must be approved by a supervisor). Note, though, that it's especially hard to pin time targets to the system itself in such cases. It's especially important that, instead, you break it down into its parts and identify ways to make each part efficient.

Four distinct ways exist for stating a response time goal:

  • Approach 1: Define a quantitative requirement. This is the commonest way and the one usually suggested. The content of this type of requirement is described in the "Strategy 1" section that follows. This is an easy option-you can simply invent a figure if you like-but it's problematic to implement and test (as argued in "Issue 1: Easy to write equals hard to implement" earlier in this chapter). A requirement of this type is of most use when deciding what hardware configuration is needed, once the system has already been built.

  • Approach 2: State it informally. Explain it for the edification of developers about what we're after, but not as a requirement. State the same information as if you were writing a requirement according to Approach 1, but write it as casual guidance for developers. Since it's informal, it needn't be as rigorous as if you were writing a requirement-but still give some thought to each of the items of information mentioned.

  • Approach 3: Define requirements for steps to take to contribute to good response times. Rather than state a quantitative performance target, it's much more fruitful to dig deeper to identify and specify steps that can be taken to give the system the best possible response time. These steps are regarded as extra requirements in this requirement pattern and are discussed in the "Extra Requirements" subsection coming up. This is the hard option but the most helpful to developers.

  • Approach 4: Say nothing. Having thought about response times for some aspect of a system, a perfectly valid option is to decide not to mention it in the requirements specification. At several points, this requirement pattern suggests saying nothing. Positive inaction!

In addition to simply choosing one of these ways, they can be combined into richer strategies. Two suggest themselves:

  • Strategy 1: Break down end-to-end quantitative target. The only response times for which we have a natural feel are those experienced by users, so this is a sensible starting point-but it's not helpful if part is outside the scope of the system. This strategy turns an end-to-end response time into one just for those parts within our control. Perform the following steps:

    1. Decide on a maximum acceptable response time to users (called end-to-end because it includes everything): for example, two seconds.

    2. Identify the constituent pieces involved in delivering the response. This need be done only at a very high level, for the purpose of allocating time to each piece. For example, everything between a Web user's PC and our back-end application could be regarded as one piece. Or you could treat the Internet as one piece and your router, firewall, Web server, and internal network as another piece. Any external system that must be called would be another piece. Some pieces might be outside the system's scope. Assume an indicative hardware set-up as necessary.

    3. Allocate a fraction of the end-to-end response time to each component (or group of components-for example, all those out of scope). This will involve some guesswork, but you probably won't go far wrong. In our example, we might allocate to our application system half a second of the overall two seconds.

    4. Specify a response time requirement for that portion that is within the scope of the system, using the amount of response time allocated to it. Alternatively, you can specify a separate requirement for each logical component within scope.

    This strategy is especially important when dealing with processes that involve human intervention (such as manual approval by a supervisor), or other kinds of nonsystem delays.

  • Strategy 2: Quantitative target and contributing steps. The aim is to get the benefit of both. Start by defining a quantitative performance target (Approach 1), and then study it and identify steps that help achieve it (Approach 3). Once you've identified these steps, you can demote the original performance target to an informal description (Approach 2).

    If requirements are being specified at two levels-that is, business requirements first and detailed requirements afterwards-Approach 1 suits the business requirements and Approach 3 the detailed requirements.

These two strategies aren't mutually exclusive: you can use the first and then the second. All these ways and strategies have their place. Which one is best depends on how important the performance target is, the scope of the system being specified (is it the software only?), the nature of your development environment (how much do you trust your developers to do a good job?), and personal preference.

Content

The following list describes what a quantitative response time requirement (as per Approach 1) should contain. It's so lengthy because it explains how thinking about a particular item of information can steer you to framing the requirement in a different way.

  1. Type of operation What does this requirement apply to? Is it for a specific function, a collection of functions, all functions for a class of users, or something else? Don't impose a demand on all user functions; apply it only to those that genuinely need it. Limit its scope as much as possible. Exclude rarely used functions. Use a requirement of this type to inform developers of those areas whose performance they should worry about.

  2. Exceptional cases Is the response time target likely to be unachievable in some cases? For example, functions that involve intensive processing will be slower, so it's unfair to judge them against the same goal. However, it's difficult to know at requirements time which functions have lots of work to do-and yet we don't want to let developers get away with inefficiency by using intensive processing as an excuse. You must find the right balance.

  3. Timing boundaries What exactly are we measuring? That is, what causes the stopwatch to start and what causes it to stop? Be precise, because differences in interpretation could profoundly affect how well the system satisfies the requirement. For example, if you're requesting a Web page (say, containing many images), are you measuring to when the page begins to display, when its main structure is displayed, or when the whole page is fully displayed (with all the images)?

    image from book

    Pick boundaries such that everything from start to finish is within the scope of the system being specified. Exclude anything over which you've got no control (such as a potentially slow public network). In fact, set the boundaries so that they span as few variable factors as possible. If you can't do this, identify indicative hardware or assumed performance (such as Internet connection speed) for the parts that are outside the system's scope-though they are in themselves hard to specify and won't behave uniformly even then. If you end up setting a target for the system's internal response time, it won't be directly observable by a user, so you need a way for the software to measure and record it (which is described in the "Response Time Monitoring" subsection of the "Extra Requirements" section later in this pattern).

  4. Tolerable length of time This is the maximum acceptable response time itself. Ordinarily, this should be an absolute quantity (two seconds, or half an hour, say), because values such as fast, quick, and imperceptible are subjective and can't be verified definitively. (I say "ordinarily" because on a rare occasion it's preferable to use a subjective measure. I have in mind the situation where we merely want to prevent unusually slow response times, rather than insist on very good ones. In this case, it's advantageous to avoid defining "unusually slow" in case anything faster is regarded as fine even if it's still slow.) It is always possible to replace a subjective value by picking an absolute quantity to represent it. For example, fast might be defined as less than one second in this context, and imperceptible as less than a twentieth of a second-in rough accordance with the frames-per-second rate of human sight: the blink of an eye.

    If we're pressured to include factors outside the system's scope, an alternative strategy is to define a unit of measurement to use as a datum and then to express a performance target in terms of this unit. For example, if we define one boing to be the time it takes to show a simple (reference) Web page, from request to completed display, then we could set the acceptable response time for some other function at four boings, or two boings plus half a second. This strategy has the advantage of taking into account the actual speed of variables outside our control. The value of a boing isn't fixed; it varies according to the environment. For a PC on a local network, a boing might be half a second; with a slow Internet connection, a boing might be five seconds. It's possible to phrase a requirement to avoid having to name your artificial unit of time. You can use the same unit in more than one requirement (in which case it's difficult to avoid naming it).

  5. Justification of length of time Where did the tolerable length of time figure come from? This could include a calculation and/or argument, or it could refer to an external source where the justification is given (such as a sizing model). If the figure is arbitrary, or you can't find a good reason for it, maybe it's not important.

  6. Indicative hardware set-up Try using this if your timing boundaries go beyond the scope of the system-especially if you're specifying software only. This must include every component that affects the response time: server machine, external services that are called, Web server, firewall, router, communications networks, client machine, and so on. Treat the unpleasantness of doing this as an incentive to push the timing boundaries as close to the system's scope as possible.

    Alternatively, you can refer to a description of indicative hardware given elsewhere.

  7. High load caveat When any system's very busy, response times are liable to degrade. You can't ignore this factor. It makes sense for a response time target to apply only up to a certain load. Don't attempt to predict at what load level it will start to degrade noticeably, but you could define a level of business activity (in terms of throughput or simultaneous users) that the system must be able to handle while still meeting response time targets.

    Something else to insist on is graceful degrading of performance under load: to not tolerate instant gridlock as soon as some threshold load is reached. It's unrealistic to specify this in precise terms, so the best approach is to ask that response times must degrade only incrementally (gradually) as load increases and that a sudden jump in response times must never occur.

  8. Motivation Why are you specifying this performance goal? Why do you need good response time? It could be so the user can get more work done (an employee), or it could be that if they're bored they'll go somewhere else (a casual Web visitor). The answer to this question might hint that a quantitative performance requirement is not the best approach: perhaps you should reformulate the requirement to tackle the motivation. For example, the motivation for a fast download of software by a Web visitor might be so that they don't give up impatiently halfway through. Since it's unreasonable to demand that a download of unknown size be done in a specified time, you could replace it by a requirement that the visitor be given an indication of progress or be sufficiently entertained while the download takes place. Displaying a progress bar might be enough. (This topic is revisited in the "Response Time Masking and Explaining" subsection.) You don't always need to state the motivation explicitly in the requirement itself, but always ask yourself what it is.

Template(s)

Open table as spreadsheet

Summary

Definition

«Operation type» response time

Each «Operation type» shall have a response time of no more than «Tolerable length of time» from «Timing boundary start» to «Timing boundary end» [when using «Indicative hardware set-up»]. This figure is based on «Justification».

[This requirement does not apply to «Exceptional cases».]

High load caveat».]

[The motivation for this requirement is «Motivation».]

Example(s)

Here are a few example response time requirements with quantitative targets:

Open table as spreadsheet

Summary

Definition

Inquiry response time

Any inquiry shall complete the display of its results, from the time the user submits the request, in no longer than 4 seconds plus the display time of a simple reference page from the same location. This figure is based on anecdotal tests indicating that users begin to lose patience soon after this time.

This requirement does not apply to inquiries across large volumes of data where arbitrary selection criteria are allowed.

Transaction switching time

The average time for the transaction switch to route a customer request to a service shall be less than 300 milliseconds.

(This figure has been calculated as one twentieth of the time that a reasonable customer would consider acceptable to wait for a typical transaction. An acceptable wait for a typical transaction is taken as 6 seconds-based on timed figures for the processing of credit card transactions.)

Web page display time

Each Web page produced by the system shall be fully displayed in no longer than 10 seconds from the time the user requested it, when using a 56k bits per second modem connection.

This requirement does not apply to pages containing one or more large images.

This requirement does not apply when the number of users currently using the system exceeds 90% of the simultaneous user capacity (as stated in «User capacity requirement ID»). Above this level, it is acceptable for the display time to increase in rough proportion to the number of simultaneous users.

Data format error response time

Any error in the format of data entered by a user shall be pointed out to the user with a suitable error message no more than 1 second after they submit the information to the system.

Note that this requirement need not rely upon network communications being fast enough: local validation on the user's machine would also satisfy it (although validation must in all cases be performed on the server side too, because not to do so would represent a security weakness).

Here are some example response time requirements that do not mention quantitative targets:

Open table as spreadsheet

Summary

Definition

User response times never excessive

No user function shall have an average response time in normal system operation that a reasonable user would consider excessive for that type of function.

Timely identity card issuance

It shall be possible to issue an employee identity card on request sufficiently fast for "while-you-wait" delivery.

Ten minutes is regarded as an acceptable wait time for the purposes of this requirement, though this should not be treated as a clear boundary between "good" and "bad." A quicker time would deliver increased user satisfaction with the system, and a longer time increased irritation.

Fast display of personal happiness calculator

A happiness club member shall get fast response when displaying the personal happiness calculator for the first time after entering the club's Web site.

(This requirement makes no judgment on how the happiness calculator is implemented. It can be taken to mean that a long delay while waiting for an applet or other software to load is unacceptable. At the same time, it cannot be read as ruling out use of such software.)

This requirement is not specified in terms of an absolute length of time, partly because display time is affected by factors outside the company's control (most notably the member's connection speed). To put it another way, to specify a time we would also need to specify the PC and communications to which it applies.

It is recognized that this requirement is stated in subjective terms-but so is deciding whether response time is too slow. Thus, the person verifying the system is granted a degree of freedom in deciding whether it feels acceptable in practice. It was decided that this was preferable to setting arbitrary targets in advance.

Extra Requirements

They're diverse and deserve thought. That's the first thing to say about extra requirements that might be written about response time, either in addition to or instead of a quantitative response time requirement. Three categories of extra requirements are discussed here, each one in its own section that follows:

  1. Steps that contribute to good response times Things to be done to help the system perform well.

  2. Response time monitoring Functions for measuring response times and letting administrators see them.

  3. Response time masking and explaining Ways to lessen the chance of a user becoming impatient or confused while waiting for a response.

Steps that Contribute to Good Response Times

There are innumerable ways to improve response times. They depend upon the nature of your system and your environment, and this section doesn't attempt to identify them. It's up to you to find any major logical steps that suit your situation, where "logical" means it addresses what we need but not how. The development team is in a position to identify other ways to deliver the best possible response times. Here are a few token examples of requirements that contribute to good response times:

Open table as spreadsheet

Summary

Definition

Reports not to impact external users

The running of internal reports and inquiries shall not perceptibly degrade response times for external users.

The intent of this requirement is that database-intensive internal reports and inquiries should use different database tables from those used for external user functions and should run on different machines.

Frequent reports efficient

All reports and inquiries that are expected to be run frequently shall be designed so as to require few database accesses.

The intent of this requirement is that summary tables should be used so as to avoid repeated reading of large numbers of records from transaction tables. Of course, generating such summary tables requires the same amount of processing, but this should be done only once (or as few times as possible) and preferably when users are not waiting.

Email processing not to impact main system

Processing related to the sending and receiving of emails shall have no performance impact on the processing of requests from customers.

It is suggested that this be achieved by running the email server software on a separate machine from the rest of the system.

Observe that the first requirement here is likely to have a major impact on the architecture of the system: two databases, which involves significant additional functionality to maintain and update, functionality for which you might or might not choose to define requirements. Also observe that the intent paragraph in each of the first two examples is expressed in terms of its effect on an expected solution but that the requirements themselves do not mandate this solution.

Response Time Monitoring

Measuring response time sounds straightforward, but it seems that however you try to do it, little practical difficulties crop up. There are three main ways to measure response times:

  1. Using the system itself This is limited to the scope of the system itself, which means a server system can measure only internal response times-which is fine if this is how your response time targets are expressed. There are two difficulties with a response time measured by the system: first, what to do with the measurement-because storing it would take machine time and effort (it can't be done within any existing database update, since the response time clock is still ticking then)-and second, the act of measuring could add a little extra work and make the response time marginally longer, so you might want to be able to switch measuring on and off.

    If the scope of your system includes software on each user's machine, that software could record response times. But you then also need means to gather that information centrally (that is, to send it back to base) and for the central system to be able to receive and store it.

  2. Using an external measurement tool There are products that do this, both commercial and free, to let you measure response times at any point in a network or on a user device. In a normal business environment, it's not sensible to consider building your own. To measure user response time, software must be installed on the user's machine, which can be restrictive. (You can't get response times for an arbitrary external visitor to your Web site, for example.)

  3. By hand Use a stopwatch to record how long something takes. This is tedious and subject to human error. The results must be recorded by hand, too. If the results are to take into account the circumstances, they must be recorded as well (date and time, network connection speed, and such like), which adds to the work. Then you have to collate the recorded results.

Often, response times are measured and checked only when testing the system, but being able to do so when the system is running live is valuable.

Once you have response time measurements, what do you want to do with them? The two main uses are to

  • Produce and present statistics. They can show response times in a variety of ways, depending on the richness of the response time data that has been gathered: per function, per class of user, or according to the system load. But gathering enough data for statistics of this sort is a major commitment.

  • Raise an alarm if response times are inadequate or grow slower.

Response Time Masking and Explaining

There are limits to how much we can reduce response times. Some types of operations are bound to take a relatively long time, such as downloading software. We have to live with it, and we must turn our attention to how we can make the user's experience as painless as possible. Even if it leads to a longer overall wait, it's probably worth it. Options include

  1. Warning the user before any possible wait This is common courtesy and should be universal, but plenty of Web sites don't do this. Also tell the user beforehand how big any download will be.

  2. Letting the user know what's happening This could be a simple message: "Download in progress." Better is a progress bar of some kind, although how hard this is to implement (or whether it's feasible at all) depends on the technology used, which you might not know at requirements time.

  3. Masking the delay So that the user doesn't perceive it or perceives it less. Perform the slow operation in the background while letting the user do something else-or keep them occupied in some other way. There are various tricks. Give the user something to read while they wait. Chop up the delay into more than one piece. Don't force a user to download parts of your software they might never use. They all involve extra work, so only insist on them if it's worth it. It might be worthwhile going to trouble for a visitor to your Web site (a potential customer) but not for a humble employee.

Some of these options might sound like solutions-that is, rightfully the preserve of the development team. If you want to leave them free to pick the best option, frame the requirement in terms of what you want to achieve (the motivation), though you can mention a suggested solution informally, too.

Here are a couple of representative example requirements:

Open table as spreadsheet

Summary

Definition

Slow operation prewarning

At any point from which the user can initiate an operation that would take longer than 20 seconds (when using a 1-Mbps Internet connection), a warning to this effect shall be displayed.

Happiness calculator download progress bar

A progress bar shall be displayed to the user while the happiness calculator software is being downloaded to the user's PC, to show what percentage of the download has been done.

Considerations for Development

Consider what a developer is expected to do with each response time requirement.

If no requirements are present for features that contribute to good response time, consider what features might be appropriate.

Considerations for Testing

Consider whether a suitable hardware set-up will be available against which to test response time requirements.

If any high-load caveats are specified, consider how to simulate a suitably heavy load in a test environment.

How are you going to measure response times accurately? Does the system itself contain any ability to measure response times? If not, and that's the only way, insist on this capability being added.




Microsoft Press - Software Requirement Patterns
Software Requirement Patterns (Best Practices)
ISBN: 0735623988
EAN: 2147483647
Year: 2007
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net