[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | Europe-Swas-Artificial-Intelligence |
|
| Moderator: | HERON::BUCHANAN |
|
| Created: | Fri Jun 03 1988 |
| Last Modified: | Thu Aug 04 1994 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 442 |
| Total number of notes: | 1429 |
128.0. "TIN - USER REQMTS INPUT ??" by HERON::KANE () Tue Aug 22 1989 17:35
THE FOLLOWING IS A MAIL CONCERNING POSSIBLE
Date: 21-Aug-1989 02:52pm ETE
From: Tim Barber @RDL
TBARBER AT A1_CHEFS at CALCOT at REO
Dept: UK Market Development
Tel No: 899-5292
TO: JIM KANE @VBO
TO: PASCAL COUTIER @VBO
Subject: FYI
I N T E R O F F I C E M E M O R A N D U M
Date: 18-Aug-1989 02:29pm ETE
From: Eric Coates
COATESE AT A1_CHEFS at CALCOT at REO
Dept: Market Development Group
IF YOU WOULD LIKE TO CONTRIBUTE TO THE USER REQUIREMENTS DOCUMENT,
PLEASE, DUE TO THE SHORT TIME FRAME (SEPT, 5TH) SEND YOUR MAIL TO
BILL DIRECTLY & PLACE A COPY OF YOUR MAIL INTO THE NOTES FILE.\
THANKS, JIM
I N T E R O F F I C E M E M O R A N D U M
DIGITAL INTEROFFICE MEMORANDUM
TO: QFD Reviewer List DATE: 17 August 1989
FROM: Bill Yerazunis
DEPT: ESTG
EXT: DTN 291-8243
ENET: GUESS::YERAZUNIS
CC: ***** LOC: DLB5-2/B3
SUBJECT: Review of User Requirements and Rankings for TIN Project
We would appreciate your review of the attached list of user
requirements and their rankings for the TIN development project.
Specifically, we would like your opinion on the following:
o Have we omitted any important user requirements?
o Are there any requirements that you think are ranked
too high or too low?
For your comments to be useful to us, we must receive them by
TUESDAY, SEPTEMBER 5.
We plan to complete the second phase of the QFD process (see
attached description) by September 11.
Thank you!
-Thanks
Bill Yerazunis (GUESS::YERAZUNIS)
TIN Language Preliminary Requirements Analysis
I) Abstract
The goal of the TIN project is to develop a new language and an associated
programming environment. TIN is based on OPS5, but it includes significant
extensions to the representational power of the language and to the ease of
integration with traditional programming languages. TIN also includes
extensions to the programming environment to support large multi-programmer
projects, including the current Rulebase internal product.
The TIN development group is using the Quality Factors Development (QFD)
technique to guide the requirements analysis process. QFD is a mediated
process which brings together customers, designers, and managers to
determine and approximately prioritize goals, needs, features, and
tradeoffs for an evolving product. The QFD process seeks to maximize
user-perceived quality in the product.
On Wednesday, June 29, 1989, a one-day QFD meeting was held to perform
the first half of the full QFD process for TIN, for a two-year planning
horizon.
Normally, the QFD process in Digital takes two full days. We have split
the process into two phases: needs analysis and feature analysis.
The result of the first half of the QFD process is a rated list of
goals, needs, and requirements for the TIN language, for the next
two years. The second half of the QFD process will generate a prioritized
list of features which address those needs.
In summary, the highest weighted requirements were either enhancements to
the representation capabilities or the removal of irritating
(and sometimes debilitating) restrictions of the current OPS5. Notable
exceptions to this general trend are the highly rated portability to MIPS-based
workstations, and SEAR integration hooks.
This document lists the QFD participants, describes the relevant parts
of the QFD process, and the results we have obtained so far.
II) QFD Participants
Attending the QFD meeting were:
Person Organization Representing
------ ------------ ------------
Bill Cahill QFD facilitator
Georg Klinker AIRG Research uses
Bea Walther ESTG (GEM/ORE) Metal integration
Robin Trei CSDG (Architecture) Large system builder
Bill Barabash ESTG (TIN) Implementor
Ken Gilbert ESTG (METAL architect Metal
Mike Grimes CSDG (TIE) Lang integration issues
Steve Kirk ESTG (TIN) Non-AI software eng.
Joyce Isen CUP (TIN Documentation) Documentation issues
Tom Cooper ESTG (SEAR/RIME) Metal integration
Cecelia Garbarino CSDG (KEG) Large system builder
Patti Lynch ESTG (SEAR) Prototyping uses
Bill Yerazunis ESTG (TIN Development) Implementor
Most of the participants represented the needs and issues they are
confronted with every day. A few people, however, represented not their
own needs but the needs of users (or potential users) whose needs they
well understood.
III) Explanation of QFD
QFD is a structured, mediated process which brings together customers,
marketers, and developers to ascertain and rate needs, desires, benefits,
and features of a product.
We began the QFD process with the results of all previous OPS5 marketing,
sales, and internal studies. This combined set of needs (over 130 elements)
was sifted and structured by the TIN development group, and served as the
starting point.
At several points, the group decided that either (1) a pair of needs was
redundant; or (2) there was really an additional need that wasn't yet
addressed. In these cases, needs were added to or struck from the working
list as appropriate. In addition, some needs were reclassified as features
and will be analyzed as such.
Each of these finalized goals, needs, or requirements was rated by
consensus of the QFD attendees on four scales:
(1) Customer Value - how do the customers (users) see the importance
of this?
The customer value is rated on the following scale:
5 = Absolutely required, essential
4 = Very important, would pay extra for it
3 = Desirable, but could live without it
2 = Nice to have, but wouldn't pay extra
1 = Couldn't care less, not useful
(2) Today's Value - how does the group see the current product (OPS5)
in this quality dimension?
(3) Rating Goal - what's the consensus of the group as to
where we realistically could be, in the
up-to-two-year term.
These two ratings are based the following scale:
5 = Perfect, or as good as is ever possible
4 = Well above average, but room for improvement
3 = About average, could do much better
2 = Only slightly meeting customer need
1 = Not meeting the need in any way
(4) Sales Points - how attractive is this benefit to a customer
who is not an advanced user?
This value rates on the following scale:
1.5 = Super sales point. "Where do I sign?"
1.2 = Interesting, worth taking second look.
"What's the cost?"
1.0 = "So what, who cares, doesn't everybody?"
After each of these four attributes have been assigned, then two additional
figures are generated: Improvement Ratio and Raw Weight.
Rating Goal
Improvement Ratio = ---------------
Today's Value
Weight = Customer Value * Improvement Ratio * Sales Points
The "Weight" number can be interpreted as an overall importance number--
a composite of both how important and how doable each of the needs is.
IV) Results of the QFD needs analysis
Below are the results of the QFD needs analysis, sorted into five tables.
Each table contains the entries for a constant CUSVAL (5, 4, 3, 2 and 1),
corresponding to the five levels of:
5 - Absolutely required, essential
4 - Very important, would pay extra for it
3 - Desirable, but could live without it
2 - Nice to have, but wouldn't pay extra
1 - Couldn't care less, not useful
Each table entry carries the six important values found in the QFD
process, and a brief explanation of what the requirement means.
The column values are:
CUSVAL - Customer Value
TODAY - Today's Value
GOAL - Rating Goal
SALES - Sales Points
IMPRAT - Improvement Ratio
WEIGHT - Raw Weight ( "importance" )
"5's" TABLE - "Absolutely required, essential"
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
Disjunctive CE's 5 1 5 1.2 5.0 30.0
Disjunctive condition elements allow a programmer
to specify an "OR" condition among WME's or groups of
WME's, not just among slot values in a single WME.
Multi concur executions 5 1 5 1.2 5.0 30.0
Allow a dev. env. user to run several copies of
the same program, on different data, at the same time.
Call build 5 1 5 1.2 5.0 30.0
Callable function to build a new rule into the
running program.
Multi-user Rulebase 5 1 5 1.2 5.0 30.0
Provide multi-granularity multi-user interlocking
on a shared rulebase.
TRACE output to file 5 1 5 1.2 5.0 30.0
Capture the output of a TRACE window into a
file for later perusal or printing.
User-mod. PPWM filter 5 1 5 1.2 5.0 30.0
Let the user define one or more prettyprinting
formats for use when examining WMEs.
Program modularity 5 1 4 1.5 4.0 30.0
Make clusters of rules independent and callable.
MIPS ULTRIX 5 1 4 1.5 4.0 30.0
Compile and run on the MIPS-based workstations.
Unlim # attribs/wme 5 1 5 1 5.0 25.0
Allow an unlimited number of attribute slots
in any WME.
Unlim # vector attr/wme 5 1 5 1 5.0 25.0
Allow more than one attribute slot in a WME
to be a vector attribute slot.
Multi-versioning Rulebase 5 1 5 1 5.0 25.0
Have Rulebase maintain a history of all changes
made to the program, not just current/reference
MIX migration path 5 1 5 1 5.0 25.0
provide ways for MIX to directly migrate to TIN
without massive rewrites.
Eliminate literal, substr 5 1 5 1 5.0 25.0
Get rid of obsolete forms like LITERAL, SUBSTR,
and others.
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
Attrib data type coercion 5 1 5 1 5.0 25.0
provide automatic type conversion among slot
values, where appropriate.
Multi-variant Rulebase 5 1 5 1 5.0 25.0
Have rulebase track variants of programs and
help in re-merging variants back together.
Callable RB interface 5 1 5 1 5.0 25.0
Document and stabilize interface to rulebase, so
other programs can get at rules without going
through development environment.
Callable ORE interface 5 1 5 1 5.0 25.0
Document and stabilize interface to ORE, so
other programs can get at stored WMEs without
writing lots of TIN glue code.
SEAR integration hooks 5 1 4 1.2 4.0 24.0
Allow SEAR to directly connect into the development
environment.
WME grouping & scoping 5 1 4 1.2 4.0 24.0
Cluster WME's together and explicitly control
visibility of these clusters to the rules
Kept YFE 5 1 4 1.2 4.0 24.0
Let user-defined editor make multiple alterations
without exiting/being reinvoked.
Couple lits, ORE, SEAR 5 1 4 1.2 4.0 24.0
Provide software coupling between literalize dec-
larations with ORE schema declarations and SEAR
template declarations.
WME histories 5 1 4 1.2 5.0 24.0
Keep a complete modification history of each
WME, from creation, through all modifications,
to final removal.
Locally scoped attrs. 5 1 4 1 4.0 20.0
Keep attr. information local to the WME slot
declaration (not global like LITERAL)
Full CE syntax in interp 5 1 4 1 4.0 20.0
Make the full match description capability of
a condition element available at command level.
Min, max, one-of LHS oper 5 2 5 1.2 2.5 15.0
Allow choice to propagate only one of the WMEs
that match, choice based on max/min/one-of
Distributed rulebase access 5 2 5 1.2 2.5 15.0
Allow rulebase interlocked access over LAN/WAN
Unique WME ids 5 2 5 1 2.5 12.5
Every WME has a unique and immutable identifier.
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
Attr from var ' ^<foo> ' 5 2 5 1 2.5 12.5
Extend CE match syntax to allow field names to be
bound variables and evaluated at run-time.
Support call standard 5 2 5 1 2.5 12.5
Allow the transparent passing of atomic data types
as parameters to other routines.
Multi-CPU capability 5 2 5 1 2.5 12.5
Do nothing which precludes future parallelism.
Pointers to WMEs as attrs 5 2 5 1 2.5 12.5
Language support for an attribute type whose
allowable values are pointers to other WMEs.
Support of RIME 5 2 3 1.2 1.5 9.0
Provide built-in support for the RIME methodology.
Fast 5 4 5 1.2 1.3 7.5
As fast as OPS5 is today.
End-user docs 5 4 5 1 1.3 6.3
Provide complete End User documentation including
Reference and User's Guides.
Extra features don't slow 5 5 5 1 1.0 5.0
Never include a language feature which inherently
slows the compiled executable, even when it is not
being used.
Bullet-proof 5 4 4 1 1.0 5.0
Language and environment are robust, well-tested,
essentially glitch-free.
Support for demons 5 4 4 1 1.0 5.0
Support rules which can fire at any time regardless
of the current module or context.
Add attr at runtime (dev) 5 2 2 1 1.0 5.0
From the Environment, support the dynamic addition of
attributes to a WME type (a prototyping feature).
Proto's as well as OPS5 5 5 4 1 0.8 4.0
Provides at least as many features which support
easy prototyping as the current OPS5.
Productizeable 5 5 4 1 .8 4.0
Ensure that it will be trivial to convert TIN
into a product at some future date.
On-line help 5 5 4 1 0.8 4.0
Provide complete on-line help on all environment
features and language constructs.
"4's" TABLE - "Very important, would pay extra for it"
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
Procedural attachments 4 1 5 1.5 5.0 30.0
Allow a function to be attached to an attribute, so
that asking the WME for that value or placing
a new value in that attribute will call the function
instead of making a direct memory reference.
BACKUP CALL hook 4 1 5 1.5 5.0 30.0
Allow a way to define a routine to call to undo
RHS callout side-effects when a BACKUP is done.
Locally scoped wme attrs 4 1 5 1.2 5.0 24.0
Keep attr. information local to the WME slot
declaration (not global like LITERAL)
Expl. control btw ruleblocks 4 1 5 1.2 5.0 24.0
provide a way for ruleblocks to explicitly
transfer control between each other.
Bookreader format 4 1 5 1.2 5.0 24.0
Put the documentation into DECWindows Bookreader
format so that it can be referenced online.
SWS Support manual 4 1 5 1.2 5.0 24.0
Provide a manual of "magic features" available
to SWS, etc. describing useful inner workings
and non-public interfaces.
Symbolic constants 4 1 5 1 5.0 20.0
Allow definition and use of symbolic constants
WBREAK on remove 4 1 5 1 5.0 20.0
make WBREAK trip a breakpoint just before the
matching WME is removed.
ARB strategy 4 1 5 1 5.0 20.0
Allow a new conflict resolution strategy that
just accepts the first available match, rather
than searching for all possible matches and
then choosing one.
Weak attrib typing 4 1 5 1 5.0 20.0
Allow optional definition of type of a slot,
check for this at compile time/run time.
Show instantiation (why-not) 4 1 5 1 5.0 20.0
Query the inference engine as to why a given
rule is not eligible to fire (or isn't next
to fire)
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
Join WMEs, manip as a unit 4 1 4 1.2 4.0 19.2
Provide a way to connect multiple WMEs together
so they can be manipulated (passed, saved, etc)
as a single unit.
Incremental decl. compile 4 1 4 1.2 4.0 19.2
Incrementally compile declarations of new WME
types at run-time in the development environment.
Source code macros 4 1 4 1.2 4.0 19.2
Provide source-code substitution macros for
programming.
Set-of-wme's LHS syntax, oper 4 1 4 1.2 4.0 19.2
Provide a way to cluster WMEs within an LHS and
perform operations on the WME cluster.
Faster saves on big prog 4 1 4 1.2 4.0 19.2
Speed up the environment to save big systems
faster.
Controllable RB hist purg 4 1 4 1.2 4.0 19.2
Provide a way to purge the stored history in the
Rulebase in a controlled way.
Faster than current OPS5 4 1 4 1.1 4.0 17.6
Faster, faster, faster!
SDL for data in/out 4 1 4 1 4.0 16.0
Map WME's to be mapped into compound data
structures (i.e. C STRUCTs, Pascal RECORDs, etc)
to interface with other languages and tools,
preferably using SDL.
Negated CE groups 4 1 3 1.2 3.0 14.4
Allow a syntax to group several CE's together and
conditionalize on "no satisfactory WME/CE
assignment exists".
Proto's better than OPS5 4 1 3 1.2 3.0 14.4
Has features which support prototype style of
development even better than OPS5 does.
TIN threads 4 1 3 1.2 3.0 14.4
Provide constructs in the language which support
coarse-grained parallelism under programmer control
(eg ADA tasks or Lisp threads).
Default attrib values 4 2 5 1.2 2.5 12.0
Allow a slot in a WME to be assigned a default
value other than NIL, if the MAKE statement
doesn't explicitly assign a value.
Full recursion (algol/lisp) 4 2 5 1.2 2.5 12.0
Support recursive invocation of TIN routines.
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
Collection attr's & opers 4 2 5 1.2 2.5 12.0
Support for an attribute type(s) whose allowable
values are really collections of values, and provide
both LHS and RHS operators for manipulating those
collections of values (eg. sets, lists, vectors, etc)
Global changes 4 2 5 1.2 2.5 12.0
Provide editing mechanism for doing repeated changes
to all the constructs in entire modules or sessions.
Use less memory 4 2 5 1.2 2.5 12.0
Design the system to support dense representations
(ie. no unused space ever allocated for objects).
Mult. indep entry points 4 2 5 1 2.5 10.0
Allow programmers to have 2 or more sub-programs
while guaranteeing that there will be no interactions
between them, unless so specified by the programmer.
Relations beyond typ/subt 4 1 2 1.2 2.0 9.6
Allow arbitrary, user-defined relations among
WME types (i.e. part-of, etc).
DW interface for user code 4 2 3 1.5 1.5 9.0
A "power-tool" package to make the generation of
simple DECwindows interfaces from TIN trivial.
User-visible timetag 4 3 5 1 1.7 6.7
Make the time-tag in each WME available to the programmer
as a read-only attribute which can be matched on.
Least Astonishment 4 3 5 1 1.7 6.7
Design by the "Least Astonisment" principle.
Easy to use 4 3 4 1.2 1.3 6.4
Language and environment designed to be simple, consistant,
and expressive. Include accelerators/power-features where
appropriate.
Improve perf. analysis 4 3 4 1.2 1.3 6.4
Provide more sophisticated (perhaps graphical)
performance monitoring and analysis tools.
Consistent menus 4 4 5 1 1.3 5.0
Make environment menu presentation consistant.
Easy to learn 4 4 4 1.2 1.0 4.8
Language and environment designed to be simple and
consistant to make it easy to learn.
"3's" TABLE: "Desirable, but could live without it"
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
Parallel TIN 3 1 5 1.5 5.0 22.5
Automatic parallel execution to gain near-linear
speedup on multi-CPU machines.
Type lattice inheritance 3 1 4 1.5 4.0 18.0
Allow a type to inherit slots, default values,
etc. from more than one parent type
PCA 3 1 3 1.2 3.0 10.8
Interface to VAX PCA.
RDB interface 3 1 3 1.2 3.0 10.8
A "power-tool" package to make the storage and
retrieval of WME's to RDB from TIN simple.
SEAR Ode interface 3 1 2 1.2 2.0 7.2
Window interface to the SEAR tool from
inside the TIN environment.
Data dict. interface 3 1 2 1.2 2.0 7.2
A "power-tool" package to use a data-dictionary
for defining TIN types.
Pass WME sets 3 1 2 1.2 2.0 7.2
Provide some mechanism for passing entire sets
of WME's to other languages
Pointers to values 3 1 2 1.2 2.0 7.2
Allow values which are pointers to values (or some
other mechanism which allows shared attribute values).
Debugger sym table 3 1 2 1 2.0 6.0
Generate object files (with symbol tables, etc)
such that the standard source code debugger
can watch inside of TIN modules.
No inherent memory leaks 3 2 4 1 2.0 6.0
Design no feature which allows memory to be allocated
which cannot be recovered.
GEM/ORE Ode Interface 3 2 3 1.2 1.5 5.4
Provide a nice window interface to ORE as part of
the TIN environment.
Unlim CE's per LHS 3 3 5 1 1.7 5.0
Eliminate the restrictions on the number of
conditions allowed per rule.
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
Restructure session 3 2 3 1 1.5 4.5
Provide some mechanism which make it easy to
restructure an entire session (ie. move rules
around without editing them).
Rule dependency graph 3 1 1 1.5 1.0 4.5
Provide graphical representation of the relations
between which rules can create/modify WMEs and the
rules which can match against them.
Command == Callable 3 3 4 1 1.3 4.0
Make all intepreter commands be callable
and RHS operations.
"2's" TABLE - "Nice to have, but wouldn't pay extra"
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
Explicit rule priorities 2 1 5 1.2 5.0 12.0
Allow programmers to explicitly specify the
precedence of rules, overriding the default
mechanism in the current CR strategy.
LSE 2 1 5 1 5.0 10.0
Provide a TIN language support mode for LSE.
CMSify rulebase 2 1 5 1 5.0 10.0
Either build Rulebase on top of CMS or provide simple
mechanism to save major baselevels into CMS.
DEMAND attr. type 2 1 3 1.5 3.0 9.0
Allow attributes to be typed as 'assume true'
which then asks for a value if there is none
(a prototyping feature).
VAX ULTRIX 2 1 4 1 4.0 8.0
Runs on VAXen running ULTRIX
User-modifiable CR 2 1 3 1.2 3.0 7.2
Provide language mechanisms which allow the programmer
to tailor the conflict resolution strategy.
OOL integration 2 1 2 1.2 2.0 4.8
Provide high-level data and procedure integration with
one (or more) object-oriented language.
IPSE support 2 1 2 1 2.0 4.0
Support the Integrated Programming Support
Environment (IPSE) when it becomes available.
Interactive 2 2 3 1 1.5 3.0
Design language to operate in small, atomic, and
preferably interruptible operations, to make it
easy to build interactive/windowing applications.
"1's" TABLE - "Couldn't care less, not useful"
Customer Attribute CUSVAL TODAY GOAL SALES IMPRAT RAW
------------------ ------ ----- ---- ----- ------ ----
DWCI 1 1 5 1.2 5.0 6.0
Provide a DECwindows interface to the compile command.
Scoped rulenames 1 1 5 1 5.0 5.0
Allow rule name to be reused in different modules.
Explicit RHS control struct 1 1 4 1 4.0 4.0
Provide some explicit RHS control structures
(eg. if-then-else, ...)
Transparent stable store 1 1 2 1 2.0 2.0
Make the interface to a database (presumably ORE)
as transparent as possible (perhaps as a WME type
qualifier 'permanent', etc.)
Debug supt for nonDW use 1 3 2 1 0.7 0.7
Provide some subset of the environment features
via a terminal interface.
| T.R | Title | User | Personal
Name | Date | Lines
|
|---|