Object Oriented Software Engineering   View all facts   Glossary   Help

subject > requirement > non-functional requirement > allowance for maintainability and enhancement

allowance for maintainability and enhancement
subject			fact

allowance for maintainability and enhancement	describes changes that are anticipated for subsequent releases
	is a subtopic of 4.5 - Types of Requirements
	is a kind of non-functional requirement
non-functional requirement	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: allowance for reusability    Up: non-functional requirement    Previous non-functional requirement: throughput