[unrev-II] Requirements 0.7 (chgs only)

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Thu Jun 01 2000 - 15:09:49 PDT

  • Next message: Rod Welch: "Re: [unrev-II] Glossary - just breaking the ice on this task"

    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"
    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
    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
    so that, for example, a section of a contract can be threaded back to
    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
            [Note: This needs thought. Are these separate relations? Or are
            they (possibly optional) attributes of a relation like
            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

    fnCentral.com: it's where you are! Be deskbound no more. No apps.
    Use the web's first fully integrated personal finance manager
    from any PC, Palm, phone, internet appliance! OPEN A FREE ACCOUNT NOW.

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:

    This archive was generated by hypermail 2b29 : Thu Jun 01 2000 - 15:17:22 PDT