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
| ![2001-08-30 14:55:40.0](facet.gif) |
do not describe particular algorithms to be used | ![2001-08-30 14:55:40.0](facet.gif) |
includes | ![2001-08-30 14:55:40.0](facet.gif) |
is a subtopic of 4.5 - Types of Requirements | ![2001-08-30 14:55:40.0](facet.gif) |
is a kind of requirements document | ![2001-08-30 14:55:40.0](facet.gif) |
requirements document | depends on | ![2001-08-30 14:57:19.0](facet.gif) |
forms the basis for testing the system | ![2001-08-30 14:57:19.0](facet.gif) |
goes through several iterations of development and review | ![2001-08-30 14:57:19.0](facet.gif) |
has version number | ![2001-08-30 14:57:19.0](facet.gif) |
has parts a clear title, and sections with meaningful headings and subheadings | ![2001-08-30 14:57:19.0](facet.gif) |
has part functional requirements | ![2001-08-30 14:57:19.0](facet.gif) |
has part non-functional requirements | ![2001-08-30 14:57:19.0](facet.gif) |
is definitive only when all the stakeholders agree they are to be implemented | ![2001-08-30 14:57:19.0](facet.gif) |
is subject to change caused by: | ![2001-08-30 14:57:19.0](facet.gif) |
must be written at a high-enough level so that the potential users can read it | ![2001-08-30 14:57:19.0](facet.gif) |
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 | ![2001-08-30 14:57:19.0](facet.gif) |
should be sufficiently complete | ![2001-08-30 14:57:19.0](facet.gif) |
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 | ![2001-08-30 14:57:19.0](facet.gif) |
should be well organized | ![2001-08-30 14:57:19.0](facet.gif) |
should be agreed to by all the stakeholders | ![2001-08-30 14:57:19.0](facet.gif) |
should be reviewed by the author and stakeholders | ![2001-08-30 14:57:19.0](facet.gif) |
should be updated when incremental changes are made to the system | ![2001-08-30 14:57:19.0](facet.gif) |
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
| ![2001-08-30 14:57:19.0](facet.gif) |
should have changes in each new version highlighted for the reader using change bars | ![2001-08-30 14:57:19.0](facet.gif) |
document | should be written for a particular audience | ![2001-08-30 14:55:21.0](facet.gif) |