response time | can be a problem due to the need to load information over a network or process large volumes of information | |
has definition The time that elapses from when a user issues a command to when the system provides enough results so the user can continue his or her work | |
is acceptable if it is at least as fast as other applications that users are accustomed to | |
is a subtopic of 4.5 - Types of Requirements | |
is a subtopic of 7.5 - Usability Principles | |
is a kind of measurement | |
is a kind of non-functional requirement | |
may be up to about 15-20 seconds for operations such as loading complex pages from the net over a modem-based connection if the user understands that they are naturally time-consuming and an indication of progress is shown | |
should appear instantaneous for some operations such as tracking the cursor, popping up of menus and echoing of input | |
should be a second or less for operations such as saving most data, moving between windows, obtaining help, and obtaining the first feedback from any longer operation | |
should be evaluated on the slowest hardware that end-users are likely to encounter | |
should not be more than 15-20 seconds unless the user interface warns the user so the user can do something else while waiting or choose not to perform the operation | |
non-functional requirement | describes a constraint that must be adhered to during development | |
restricts the freedom of software engineers as they make design decisions because it limits what resources can be used and sets bounds on aspects of the software's quality | |
requirement | can be gathered from various stakeholders, other software systems and any documentation that might be available | |
changes regularly | |
has part problem statement | |
indicates how the system is to behave | |
is expressed as a fact | |
is grouped with other requirements into a requirements document | |
is normally expressed in a natural language such as English (using present tense and active voice), sometimes supplemented by a formal mathematical language, and often by some form of diagram | |
may be given a unique number for traceability | |
may be shown as a diagram | |
must be agreed upon by all stakeholders | |
should be analysed if there is any doubt whether it is realistic | |
should be changed whenever the benefits of doing so outweigh the costs | |
should be cut if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop | |
should be expressed using clear and consistent notation, using language that the customers can understand, and consistent with the other requirements | |
should have benefits that outweigh the costs of development | |
should help solve a customer's problem | |
should lead to a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable | |
should not indicate how it will be implemented in order to give the designer as much freedom as possible to make decisions | |
should not over-constrain the design of the system | |