Object Oriented Software Engineering   View all facts   Glossary   Help

subject > representation > document > requirements document > requirements document derived from use cases

requirements document derived from use cases
subject			fact

requirements document derived from use cases	does not usually lead to innovative solutions
	is a subtopic of 7.3 - Developing Use Case Models of Systems
	is a kind of requirements document
	tends to mirror mirror the way users worked before the software was developed
requirements document	contains functional and non-functional requirements
	depends on The size of the system The need to interface to other systems The target audience The contractual arrangements for development The stage in requirements gathering The level of experience with the domain and the technology The cost incurred if the requirements are faulty
	forms the basis for testing the system
	goes through several iterations of development and review
	has version number
	has parts a clear title, and sections with meaningful headings and subheadings
	has part functional requirements
	has part non-functional requirements
	is definitive only when all the stakeholders agree they are to be implemented
	is subject to change caused by: Business process change Technology change Better understanding of the problem
	must be written at a high-enough level so that the potential users can read it
	must not be too large at an early stage in requirements gathering because the risk that these will have to be completely re-written is too great
	should be sufficiently complete
	should be well designed so its structure can be easily understood, so it can be quickly scanned and so any given requirement can be easily found
	should be well organized
	should be agreed to by all the stakeholders
	should be reviewed by the author and stakeholders
	should be updated when incremental changes are made to the system
	should contain rationale for all requirements that involve a large amount of analysis, that are controversial or for which several alternatives are considered, so that software engineers in the future do not have to repeat your analysis when they make changes, the reader is convinced that you did in fact consider the alternatives, and the reader is alerted to the fact that the requirement may be controversial
	should have sections Problem: A succinct description of the problem the system is solving Background information: information that will help readers understand the requirements. It should contain references to domain analysis documents Environment and system models: the context in which the system runs and a global overview of the system or subsystem Functional Requirements: Services provided to the user and to other systems Non-functional requirements: any constraints that must be imposed on the design of the system
	should have changes in each new version highlighted for the reader using change bars
	should not contain requirements in the introduction and conclusion to avoid the problem of changing the requirements in one place and forgetting to change them in another place
document	should be written for a particular audience

Next requirements document: requirements document for a large system    Up: requirements document    Previous requirements document: requirements definition