Assumptions are unproven Conditions, which if not true at some defined point in time, would threaten something, such as the validity of a specification or the achievement of our Requirements.

‘Assumption’ is a Parameter that can be used to explicitly specify any Assumptions made in connection with a specific statement.

Alternative Names

Concept Number: *002
English Master: Assumption
Synonyms, Variations & Acronyms: none


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




Parameter, Risk analysis Concept.


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

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.

2. The purpose of the Assumption Parameter is to explicitly state ‘otherwise hidden’ or unDocumented Assumptions. This permits Systematic Risk analysis.

3. There are many different ways in Planguage to express Assumptions. Alternatives to using the Assumption Parameter include using the Rationale, Condition and Basis Parameters.

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.

Keyed Icons


Drawn Icons



History of Concept


This Concept entered by Kai.

Created by system. Last Modification: Thursday 11 of July, 2019 13:38:30 CEST by Admin (Kai).

Concept Search