Object Oriented Software Engineering   View all facts   Glossary   Help

subject > requirement > implicit requirement

implicit requirement
subject			fact

implicit requirement	has definition A requirement not stated explicitly in the requirements document
	is a subtopic of 10.1 - Basic Definitions
	is discovered when a user or tester runs the system
	is a kind of requirement
requirement	can be gathered from various stakeholders, other software systems and any documentation that might be available
	changes regularly
	does not describe how the system will be implemented
	does not describe the domain
	has part problem statement
	indicates how the system is to behave
	is concise
	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 important for the solution of the current problem
	should be logically consistent
	should be realistic with available resources
	should be unambiguous
	should be uniquely identifiable
	should be verifiable
	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 requirement: non-functional requirement    Up: requirement    Previous requirement: functional requirement