Object Oriented Software Engineering   View all facts   Glossary   Help

subject > representation > document > requirements document > requirements document for a large system

requirements document for a large system
subject			fact

requirements document for a large system	consists of a series of documents arranged in a hierarchy
	is more detailed than the requirements document for a small system because there is more to say and because the system will need to be divided into subsystems so that different teams can work on each part
	is a subtopic of 4.7 - Types of Requirements Document
	is a kind of requirements document
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 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
	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: functional requirements    Up: requirements document    Previous requirements document: requirements document derived from use cases