Subject |
indicate |
cut |
express in |
have |
agree upon by |
analysed |
be |
gather from |
solve |
is a kind of |
is a subtopic of |
express as |
show as |
specify in terms of |
describe |
lead to |
group with |
restrict |
give |
change |
has part |
has definition |
express using |
over-constrain |
measurement | | | | | | | | | | subject | 1.5 - Software Quality | | | | | | | | | | | | | |
non-functional requirement | how it will be implemented in order to give the designer as much freedom as possible to make decisions | if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop | 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 | benefits that outweigh the costs of development | all stakeholders | if there is any doubt whether it is realistic | verifiable by measuring various aspects of the system and seeing if the measurements conform with the requirement | various stakeholders, other software systems and any documentation that might be available | a customer's problem | requirement | 4.5 - Types of Requirements | a fact | a diagram | | a constraint that must be adhered to during development | a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable | other requirements into a requirements document | 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 | a unique number for traceability | whenever the benefits of doing so outweigh the costs | problem statement | A requirement that constrains design of a system, but does not describe a service that the system is to provide | clear and consistent notation, using language that the customers can understand, and consistent with the other requirements | the design of the system |
throughput | how it will be implemented in order to give the designer as much freedom as possible to make decisions | if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop | 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 | benefits that outweigh the costs of development | all stakeholders | if there is any doubt whether it is realistic | verifiable by measuring various aspects of the system and seeing if the measurements conform with the requirement | various stakeholders, other software systems and any documentation that might be available | a customer's problem | non-functional requirement | 4.5 - Types of Requirements | a fact | a diagram | computations or transactions per minute | a constraint that must be adhered to during development | a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable | other requirements into a requirements document | 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 | a unique number for traceability | whenever the benefits of doing so outweigh the costs | problem statement | | clear and consistent notation, using language that the customers can understand, and consistent with the other requirements | the design of the system |