Detailing

Assumptions are suppositions, conjectures, and beliefs which lack verification at the time of writing, or Requirements and expectations that are not within our power to control, but which have been used as part of the Basis for Planning future actions. We identify for each the degree of Risk involved and possible consequences if the Assumption is erroneous. <- Don Mills. NZ 2002. donm at softed.com

Illustrations

Examples

Example1:
Assumption: Cell phones will not be available in remote places. Therefore people will buy satellite phones.

Example2:
Hierarchic Structure [Health and Safety System]:
Type: Design-Specification.
Description: A hierarchical database structure will be used.
Assumption: No negative Impact on performance of Emergency and Rescue Inquiries←JB.
Impacts: Access Response, Portability.
Impacted-By: Available database packages.
Rationale: This structure is compatible with the current structure, and can be directly converted to it.
Condition: Off-the-shelf software can be used, and no in-house support is needed.
Basis: Health and Safety System required by National Law.

1. We need to Document our Assumptions Systematically in order to give warning signals about any Conditions that need to be evaluated, or checked, to ensure that a specification is valid. The Aim is that the Assumptions will be considered at the relevant future points in time, and that anyone with any additional information concerning an Assumption (including lack of specification of an Assumption), will volunteer it as soon as possible.

4. It would be good practice to specify the consequences of a failure for the Assumption to be true. Use Impacts, Supports and similar Parameters just below the Assumption statement. See above example.

5. It would be good practice to specify the things that determine if this Assumption is going to be true. Use Depends-On, Authority, Source, Impacted-By and similar Parameters just below the Assumption statement. See above example.