Discover Inquirement

Inquirement is built to find a Solution based on Requirements. It is built to guide you through this process: to gradually explore the possible solutions in more and more detail and to discover derived Requirements that are applicable for each Option. This process creates a branch structure, where one of the branches leads to the Optimal Solution.

The Inquirement objects

The Inquirement objects are nodes that have relations. The nodes and relations are shown in the chart below. The Project, User Stories and Mandate are the Project setup. The Requirements directly derived from the User Stories are the Top Level Requirements. Requirements are grouped into Design Problems. Options are candidates to solve the Design Problem. Arguments state that an Option can or cannot solve the Design Problem. Arguments either define new Requirements that must be satisfied or reference Evidence to proof an Option solves the Design Problem. The loop Requirement → Design Problem → Option → Argument → Requirement starts high level and goes into more and more detail, until all Arguments lead to Evidence.

The power of this approach is that the Project can (and should) be started with very little User Stories and Top Level Requirements. More detailed Requirements will evolve due to the Arguments during the process. Design Problems should ideally capture the two or three most important contradicting Requirements first (e.g. strong versus light weight). Later Design Problems will deal with the easier Requirements later.

Inquirement objects and relations

Project

A Project node is the top node. It defines the name and a description of the discovery project.

User Story

A User Story node is an informal description of what the discovery project should deliver. The User Story node is translated into a formal Requirement through a Mandate Node.

Mandate

A Mandate node is the approval of the Project owner to execute the Project. A Mandate defines to which level the final project solution must be proven. The levels are derived from technology readiness levels.

  1. No level
  2. Basic principles observed
  3. Technology concept formulated
  4. Experimental proof of concept
  5. Technology validated in a lab
  6. Technology validated in relevant environment
  7. Technology demonstrated in relevant environment
  8. System prototype demonstration in operational environment
  9. System complete and qualified
  10. Actual system proven in operational environment

The Evidence node provides a certain level of confidence that a solution is proven up to a certain level.

Requirement

A Requirement node defines a Requirement that can be:

  • Functional: if the Requirement does not define any quantitative value;
  • Goal: if a number or property must be as small/large as possible;
  • Range: if a number or property must be smaller or larger than a certain value;
  • Fixed Value: if a number or property must be a certain value.

A Top level Requirement is derived from a User Story node directly.

Design Problem

A Design Problem is the node that collects certain Requirements to properly define the challenge at hand. The Design Problem should collect all Requirements that need to be satisfied. Any Options proposed to solve the Design Problem should satisfy all linked Requirements.

Option

An Option node describes a possible Solution for the Design Problem. Argument nodes are used to explain why.

Argument

An Argument is the node that explains why a Requirement is valid for a certain Option. The Argument also states the conditions for this Requirement to be valid. These conditions are defined as Requirements or Evidence. During a brainstorm, any risk or scepticism about an Option can be expressed as these conditions. Any doubt is captured and turned into a challenge that can later be solved.

Evidence

An Evidence node is the reference to Evidence that a certain Option can satisfy a certain Requirement. Evidence proves the Option validity to a certain level. The levels are derived from technology readiness levels. The Mandate node defines to what readiness level the final solution must be proven.

  1. No level set
  2. Basic principles observed
  3. Technology concept formulated
  4. Experimental proof of concept
  5. Technology validated in a lab
  6. Technology validated in relevant environment
  7. Technology demonstrated in relevant environment
  8. System prototype demonstration in operational environment
  9. System complete and qualified
  10. Actual system proven in operational environment

As the readiness levels suggest, the Evidence can have several sources: analysis, test up to proven in actual environment.