Email this page to a friend   

Email to a friend


(Alias: explanation, justification)

An explanation of the reasoning behind a decision, statement of requirement, design approach etc.

Rationales have the following objectives:

  • Communication. Rationales communicate the reasoning behind various requirements or development approaches to development teams
  • Make reasoning visible. If reasoning is made visible, defects in reasoning may be identified
  • Prevent loss of essential capabilities. The existence of rationales often prevents essential requirements/design components from being negotiated out after a passage of time when the reasons for there inclusion have been forgotten
  • Document dependencies. Rationales may be used to document the dependence of one capability on the existence of another thus preventing the introduction of inconsistencies by elimination or inappropriate modification
  • Prevent unnecessary rework. If the rationale behind a complex decision is not recorded it is often lost with the passage of time. In this case development teams often doubt the validity of the decision and set about repeating the reasoning process only to come to the same result
  • Support traceability. Rationales may be used to document the prior existing specification, design description, policy or procedure which triggered the need for a system component or capability.

Rationale Components

  • Issue. A problem, concern, or question that requires discussion for the problem solving to proceed
  • Position. A statement or assertion that responds to an issue
  • Argument. Statements that support or object to a position
  • Assumption. The basis for an argument
  • Decision. Resolving issues by selecting a position.

Rationale Component Relationships

Rational Relationships

An Example of a Rationale


Oxygen masks shall be deployed for use by passengers within five seconds of the cabin pressure dropping below 10 PSI.


  • Issue: how long does it take a passenger to become distressed through lack of oxygen?
  • Position 1: ten seconds at 10 PSI
  • Position 2: five seconds at 10 PSI
  • Argument: we don't want any distress
  • Assumption: any airline that causes its passengers distress goes out of business
  • Decision 1: choose five seconds at 10 PSI
  • Decision 2: this requirement is mandatory and nonnegotiable.

Member Comments


18 member ratings

✭ ✭ ✭ ✭ ✩

RE Definition: Rationale

start creating software

By Kolja-kust » Fri 26-May-2023, 23:53, My rating: ✭ ✭ ✭ ✭ ✭

The main point must be that everyone who wants to start creating software should determine a few points and one of them is how much and who you have to hire, now there is even a special Dedicated team cost calculator which allows you to pre-compose the composition and number of such a team for each individual stage of software creation!

24 Comments  • Page 5 of 24 •        Previous « 1…  3   4   5   6   7  …24 » Next

- Rate this definition.
- Did it help?
- Suggest improvements.
- Request more information.
- Exchange ideas with our member community.

Email to a friend