| 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 |  |
| has definition An important quality of software that measures the frequency of failures, as encountered by testers and end-users | |
| depends on the number of mistakes made by the software engineers who developed the software | |
| is more important than efficiency in a safety-critical system | |
| is a subtopic of 1.5 - Software Quality | |
| is a subtopic of 10.1 - Basic Definitions | |
| is a subtopic of 4.5 - Types of Requirements | |
| is affected by complexity of code | |
| is affected indirectly by commenting | |
| is specified as the average amount of time between failures or the probability of a failure in a given period | |
| is a kind of external software quality | |
| is a kind of measurement | |
| is a kind of non-functional requirement | |
| external software quality | can be observed by stakeholders | |
| has a direct impact on stakeholders | |
| 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 | |
Object Oriented Software Engineering View all facts Glossary Help
