Managing requirements with Truenumbers
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.
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 to represent the document association of UR-25 could be:
@document:4:1:3, @title = "Make payment"
and we can also use tags for an ID, and to show how we can link this requirement to another with ID 593, using a “satisfies” relation:
This shows it’s pretty easy to express DOORS’ constructs. Truenumbers query capability, and integration with MS-Office also make it easy to generate reports or add new requirements.
The takeaway 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. Truenumbers uses structured natural language to define data, so we’d want to capture requirements as richer, actionable knowledge, not unstructured text. There are no built-in vocabularies in truenumbers, so we arrive at our vocabularies
Let’s focus on the text of UR-25 and UR-29 in the DOORS screenshot above:
“user shall be able to use any major credit card for payment”
“user shall be able to review a flight reservation at any time prior to departure“
These are both talking about a reservation (though UR-25 doesn’t mention it). There are two user actions that are the subjects of these requirements, payment and review.
Here are candidate truenumbers for these requirements
required method for the payment action on a reservation, is a major credit-card. last availability time for review action of reservation, is departure time of the flight of the reservation.
The phrases in these sentences parse into paths, for example,
review action of reservation becomes reservation/action:review with the slash (/) representing a belonging, or part-of relationship, and the colon (:) an adjective, or kind-of relationship. You can recover the phrase by reading the path right to left and substituting the word “of” or “for” when you encounter a slash.
Paths with common roots form trees. The tree at left contains all the phrases about a reservation in the 2 truenumbers above.
Phrase vocabularies and the sentences build from the 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.
This replaces some of the labeling feature RM tools need. 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