![]() |
subject > requirement > non-functional requirement > development process to be used |
![]() ![]() | ||||
development process to be used | ||||
subject | fact |
development process to be used | has example certain approaches to testing | ![]() |
is a subtopic of 4.5 - Types of Requirements | ![]() | |
is a kind of non-functional requirement | ![]() | |
non-functional requirement | describes a constraint that must be adhered to during development | ![]() |
must be verifiable by measuring various aspects of the system and seeing if the measurements conform with the requirement | ![]() | |
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 | ![]() |
Next non-functional requirement: platform Up: non-functional requirement Previous non-functional requirement: cost and delivery date