low reliability | is a subtopic of 1.5 - Software Quality | ![2001-08-30 14:56:32.0](facet.gif) |
is a kind of reliability | ![2001-08-30 14:56:32.0](facet.gif) |
may be caused by low maintainability | ![2001-08-30 14:56:32.0](facet.gif) |
reliability | can be improved by ensuring the software is easy to implement and change, and also ensuring that if failures occur, the system can handle them or can recover easily | ![2001-08-30 14:57:16.0](facet.gif) |
depends on the number of mistakes made by the software engineers who developed the software | ![2001-08-30 14:57:16.0](facet.gif) |
is more important than efficiency in a safety-critical system | ![2001-08-30 14:57:16.0](facet.gif) |
is affected by complexity of code | ![2001-08-30 14:57:16.0](facet.gif) |
is affected indirectly by commenting | ![2001-08-30 14:57:16.0](facet.gif) |
is specified as the average amount of time between failures or the probability of a failure in a given period | ![2001-08-30 14:57:16.0](facet.gif) |
external software quality | can be observed by stakeholders | ![2001-08-30 14:55:34.0](facet.gif) |
has a direct impact on stakeholders | ![2001-08-30 14:55:34.0](facet.gif) |
non-functional requirement | describes a constraint that must be adhered to during development | ![2001-08-30 14:56:41.0](facet.gif) |
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 | ![2001-08-30 14:56:41.0](facet.gif) |
requirement | can be gathered from various stakeholders, other software systems and any documentation that might be available | ![2001-08-30 14:57:17.0](facet.gif) |
changes regularly | ![2001-08-30 14:57:17.0](facet.gif) |
has part problem statement | ![2001-08-30 14:57:17.0](facet.gif) |
indicates how the system is to behave | ![2001-08-30 14:57:17.0](facet.gif) |
is expressed as a fact | ![2001-08-30 14:57:17.0](facet.gif) |
is grouped with other requirements into a requirements document | ![2001-08-30 14:57:17.0](facet.gif) |
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 | ![2001-08-30 14:57:17.0](facet.gif) |
may be given a unique number for traceability | ![2001-08-30 14:57:17.0](facet.gif) |
may be shown as a diagram | ![2001-08-30 14:57:17.0](facet.gif) |
must be agreed upon by all stakeholders | ![2001-08-30 14:57:17.0](facet.gif) |
should be analysed if there is any doubt whether it is realistic | ![2001-08-30 14:57:17.0](facet.gif) |
should be changed whenever the benefits of doing so outweigh the costs | ![2001-08-30 14:57:17.0](facet.gif) |
should be cut if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop | ![2001-08-30 14:57:17.0](facet.gif) |
should be expressed using clear and consistent notation, using language that the customers can understand, and consistent with the other requirements | ![2001-08-30 14:57:17.0](facet.gif) |
should have benefits that outweigh the costs of development | ![2001-08-30 14:57:17.0](facet.gif) |
should help solve a customer's problem | ![2001-08-30 14:57:17.0](facet.gif) |
should lead to a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable | ![2001-08-30 14:57:17.0](facet.gif) |
should not indicate how it will be implemented in order to give the designer as much freedom as possible to make decisions | ![2001-08-30 14:57:17.0](facet.gif) |
should not over-constrain the design of the system | ![2001-08-30 14:57:17.0](facet.gif) |