Object Oriented Software Engineering   View all facts   Glossary   Help

subject > representation > document > requirements document > functional requirements

functional requirements
subject			fact

functional requirements	contains What inputs the system should accept, and under what conditions What outputs the system should produce, and under what conditions What data the system should store that other systems might use What computations the system should perform The timing and synchronization of the above
	do not describe particular algorithms to be used
	includes everything that a user of the system would need to know regarding what the system does, and everything that would concern any other system that will have to interface to this system
	is a subtopic of 4.5 - Types of Requirements
	is a kind of requirements document
requirements document	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 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
document	should be written for a particular audience

Next requirements document: non-functional requirements    Up: requirements document    Previous requirements document: requirements document for a large system