The requirements are forming in my mind ... changing ... changing ... there! Naturally I won’t be sharing them with you.
— Dilbert

In this use-case, we show that it is possible to state requirements directly in truenumbers without using Requirements Management (RM) tools like IBM DOORS. We will see that in doing so, we capture more useful aspects of those requirements.

doors-1.png

What RM tools do

The main functions of RM tools are to manage changes, history, and access control for requirements. Also to allow links to files or between requirements. DOORS is basically an object-oriented container for requirements written as text. At right is a view of DOORS objects, one or two are used as examples below.

Example 1: DOORS-like

Requirement UR-26 has text “user shall be able to use any major credit card for payment.” It is associated with a subsection in a document with heading specified in a separate DOORS object UR-25.

A simple truenumber for UR-26 leaves it as the text value of a “user requirement”:

user requirement has text = “user shall be able to use any major credit card for payment”

Tags on this truenumber can represent DOORS object UR-25, which associates requirement UR-26 to a document section:

@document:4:1:3, @title = "Make payment"

This shows it’s pretty easy to express DOORS’ constructs with truenumbers. Truenumbers query capability, and integration with MS-Office also make it easy to generate reports or add new requirements.

The point here is not “replace DOORS”, it’s that Truenumbers makes it possible to specify and manage any kind of data directly without resorting to complex, specialized application silos for every type of data you need to work with.

Example 2: Truenumbers-like

With all its power to manage them, DOORS requirements are just text, as the above example shows. Truenumbers uses structured natural language to define data, so we would want to capture requirements as richer, actionable knowledge, not unstructured text. Let’s do that for requirements UR-26 and UR-29 from the DOORS screenshot above:

UR-26: “user shall be able to use any major credit card for payment

UR-29: “user shall be able to review a flight reservation at any time prior to departure

These are both talking about a reservation (though UR-26 doesn’t mention it explicitly). They refer to two user actions payment and review, that are the subjects of these requirements. A required method for the payment action is given, and a required end time for being able to perform the review action. That end time is given as the departure time of the flight associated with the reservation.

Here are sentences that express these requirements as truenumbers of the form <property> OF <subject> is <value>

required method OF the payment action of a reservation,
  is major credit-card currency.
required last availability time OF the review action of a reservation,
  is the departure time of the flight of the reservation.
doorsTrees.png

The phrases making up these sentences can be represented as paths, for example, the <subject> review action of a reservation becomes reservation/action:review with the slash (/) representing a belonging, or part-of relationship, and the colon (:) an adjective, or kind-of relationship.

Paths with common roots form trees. The trees at left contain all the phrases regarding a reservation in the truenumbers above.

You can recite a phrase, reading it right to left, and substituting the word “of” when you encounter a slash.

Phrase vocabularies

Phrase vocabularies and the sentences built from them are what give Truenumbers its generality and power. These are not data structures, or object hierarchies. They are structured vocabularies of the phrases we use to talk about something. In this example, we plainly see that these requirements revolve around reservations, and that we talk about 2 user actions, for payment, and for review of a reservation. Also that a required method, and last availability time are the properties of interest in these requirements.

Truenumbers are immutable, eliminating the need for change management and history keeping DOORS needs because its objects can be updated. We don’t expect to compete with RM tools, but it’s interesting how far having intelligible data goes in reducing the need for special-purpose applications