Eric Armstrong
eric.armstrong@eng.sun.com



Memorandum

Date: Thu, 01 Jun 2000 15:09:49 -0700

From:   Eric Armstrong
eric.armstrong@eng.sun.com
Reply-To: unrev-II@egroups.com

To:     unrev2 unrev-II@egroups.com

Subject:   Requirements 0.7 (chgs only)

Apply this update to construct version 0.7 of the requirements document:

  1. Change the version number to 0.7

  2. Under Version History, add: 0.7 "Categorizable" section expanded, "Relational" requirement added under "DKR Requirements"

  3. In the General Characteristics section, add "Relational" after "Firewalled"

  4. Add the following paragraphs to the "Categorizable" section

    The Traction system probably presents that most clearly-thought out and well-implemented approach to Categories. In that system, categories are implemented as lists. When a category is applied to a node, the node acquires a link to the list, and also becomes a member of it. The fact that nodes are members of category lists allows efficient searches. The fact that each node links to the categories it belongs to allows all of the nodes categories to be displayed in a list (to the right of the paragraph, in Traction, in a light blue color).

    In Traction, categories can also be hierarchical.

    The colon- convention is used to separate categories, as in "logic:assert" or "logic:deny". Categories can also be changed in that system. In the demo that Chris Nuzum was kind enough to give me, he used the example of "ToDo" changing to "Feature:Scheduled" and "Bug:Open". When you invoke the change operation, all of the nodes currently marked "ToDo" are listed, and flagged as "subject to the change". You can then uncheck any nodes the change does not apply to before performing the operation. Then, when you change the remaining "ToDo" nodes, the list is all set to carry out the change.

    In addition to those features, Traction realized that the impact of changes could be large, so they included an *audit trail* for every change. When a node is recategorized, the date, time, and author of the change are recorded. It may also be possible to undo such changes, though I'm not sure. But the important point is that changes in such a system can generate a significant amount of confustion. The audit trail makes it possible to see what happened. It would also be helpful to identify folks you would rather not have messing around in your data base.

  5. Add the following after "Firewalled" in the "DKR Requirements" section

    RELATIONAL

    It must be possible to add *relations* as first-class objects in the system, where a "first class" object is one that can be observed and manipulated like any other node in the system. Such relations will make it possible to link nodes in interesting ways, make it possible to add new connections over time, and allow for some forms of automated reasoning (or at least, " reasoning assistance"). In conjunction with categories, the addition of relations is likely to be the most important step in converting the system into a true DKR, of the kind that Jack Park describes.

    Relations should work like much like categories, with the capacity for adding and changing relations, while keeping an audit trail of the modifications. However, while categories apply to single nodes, relations relate pairs of nodes, at a minimum, or possibly multiple nodes at one time. As Dewain Delp observed, the repository of information nodes in the system is more properly described as a "network", rather than a "hierarchy", because a single node may be simultaneously part of several document structures. (Even though any one view will most probably (and valuably) be hierarchical.) With the advent of relations, the system is immediately and obvisouly a true network.

    An equivalence relation, for example, could be used to relate a new question to an existing thread. The sender of the question, now alerted to the equivalence relation, can then readily inspect the answers that have been previously been given. (There are likely to be several answers in the system. By giving high marks to the answer(s) that were found to be most helpful, the best answers "float to the top" in an organic, evolving FAQ.)

    Another useful relation is "implies". The ability to add implications to the system lets the user create connections between nodes. The inverse of that relation (implied by) allows a user to trace back the rasion d'etre for a given node. In a software design network, implications allow functional requirements to be linked to each other and to design requirements, which can then be linked to specifications, and from there to code. If "not" is introduced at any stage (as in, "we can't do this) then the proposal under attack can be traced back to its roots -- with alternatives available at each stage. If the design proposal is invalid for example, perhaps one of the design alternatives that has been discussed will be usable. Failing that, the functional requirement can be reconsidered, etc.

    The ability to add relations will provide the kind of "alignment" that Rod Welch talks about -- the ability to thread document sections together so that, for example, a section of a contract can be threaded back to the email discussions that prompted it, making it easier to ensure that the final contract accurately reflects the desired goals.

    Although users can add relations at will, it makes sense for the system to come with a "starter set" of standard relations that everyone uses by convention. That initial set can come from the fields of logic, mathematics, and abstract reasoning:

    • Logic

      implies

      negates/contradicts

      and/or

      [Note: This needs thought. Are these separate relations? Or are they (possibly optional) attributes of a relation like "implies". For example, a design idea might be "implied by" multiple functional requirements. The fact that a single idea solves multiple problems makes it an elegant solution. In that sense, the relation is an "and" of the requirements. But at the same time, dropping all but one of those requirements would still imply the design idea. In that sense, the relation would be an "or". In general, (a*b) => c and (a+b) => c do not imply any relation between a and b, but only between the a,b, pair (in some particular configuration) and c. However, even if and/or are *not* relations in their own right, some mechanism for specifing such connections may still be useful -- even if it is only an attribute of a relationship.]

    • Mathematics

      equivalent to

      iff (double implication)

      set/subset, union/intersection

      [Here again is a situation similar to and/or. Is a set a relation in its own right, or a collection defined by a many:1, 1:many, or many:many relation? Should set operations like union and intersection be expressed as static relations, or are they dynamic properties of the evolving network of nodes?]

    • Abstract Reasoning

      analagous to, similar to, like

      instance of, special case of

      abstraction of, general case of


Sincerely,



Eric Armstrong
eric.armstrong@eng.sun.com