.title "ECAT USER REQUIREMENTS" "ECAT Requirements"

This document is a synthesis of the <Final ECAT User Requirements>\**
.(f
\** Version from June 30, 1995.
.)f
and several discussions between members of the MIT and NetMarket teams.
In many cases, the language is taken directly from the <Final ECAT User
Requirements>.

.chapter "User Interface Requirements"

<N.b. that this chapter contains the information in the Final ECAT User
Requirements, but does not yet contain the detailed information required for
vendor implementations.>

.sh 2 "MIT Home Page"

Users should be able to connect to ECAT from the MIT home page.

.sh 2 "Consistency across Vendors"

The "MIT Launchpad" pages and any front-end pages to the vendor's catalog
should look and operate consistently regardless of vendor.  For example,
scroll bars, menus, tab and carriage return, navigating commands, etc. should
all behave consistently.


It should be obvious where to look for items and how to do a search.  Users
should be able to search for an item by manufacturer, manufacturer part
number, generic name (e.g., file folders), product name (e.g., Papermate med
pt pen), product category (e.g., paper), distributor part number, and
industry-standard SKU number.


It should be intuitively obvious how to use the ECAT.  Minimal documentation
and orientation should be required to train users who are (a) familiar with
placing non-electronic orders and (b) accustomed to using computers for office
applications.

.sh 2 "General Requirements"


If an unauthorized user attempts to access ECAT, the system should display an
appropriate error message.  If the un-authorized user is a member of the MIT
community, the message should inform him/her how to become an authorized ECAT
user. If the unauthorized user is attempting to access ECAT from a non-MIT
location, the message should state that the ECAT is not accessible for use
outside the MIT community.


The confidentiality of the ECAT pricing and other information should be
announced to all users accessing the ECAT, either by an initial message seen
at the beginning of every session, or by a "footer" at the bottom of each
page, such as "MIT-confidential - For Internal Use Only."


There should be on-line help which describes the features of ECAT, such as,
how to place an order, search catalogs, return an order, etc.


The on-line help should be context-sensitive.

.sh 2 "User Profiles"


To reduce data entry error and to enhance ease of use, data fields should be
pre-filled as much as possible.  Information such as username, telephone
number, ship to address, date of order, Pro-card number, and authorized MIT
account numbers should display automatically on the first screen.


Fields should offer more detail if required. For example, the user should be
able to click on a popup list and select the account number to
which he/she wants to charge the order. Other data fields, such as date
required and addressee, must be editable.

.sh 2 "Basic Functionality of Launch Page"


A user should be able to point and click to the options available to them at
the beginning of a session. Those options would be:

.bu
help/tutorial program
.bu
choice of a list of vendor sites to browse <(VWR Scientific and Office Depot in
the alpha release)>
.bu
Item search (see later section)
.lp

.sh 2 "Basic Functionality of a Vendor Page"


Once a user arrives at a vendor, either by selecting the vendor name or
through an item search in the index database(see below), the user should have
the following three options:

.bu
<Not in alpha release.
Place (or modify) a standing order. A standing order is an order that is
filled at specified intervals. E.g., an order for 5 cases of copy paper to be
shipped at the first of each month.>

.bu
<Not in alpha release.
View a list of frequently-ordered items (this is a list of items most often
ordered by the user, from which he/she can click to create an order.  Users
should be able to create and maintain multiple frequently-ordered item lists.)

.bu
Browse the vendor catalog and subsequently create an order, if desired.

.bu
Select an old order to edit and "reuse".

<Although standing orders are not supported in the alpha release, the
ability to select and edit old orders, means that this is not a
substantial limitation.>

.sh 3 "Item Pictures"


The ECAT should display pictures of items, where such pictures would be
useful.  Graphics should be standard four color catalog quality.

.sh 3 "Item Descriptions"


Items should have complete descriptions so that it is clear to the user what
he/she is ordering.  Users should not have to refer to a hard-copy catalog for
more information before determining the correct part number (or call the
vendor 800 number or the vendors' on-site campus representatives for more
information.)

.sh 3 "Order Review"


Before placing the order, the user should be able to view his/her total order
on the screen, to review all items for accuracy.  Quantity, unit of measure,
part number, description, price and price extensions, account numbers to be
charged, and total amount should be displayed.

.sh 2 "Order Routing"


<Not in alpha release.>


<MIT users without purchasing authorization need the ability to browse the
catalog -- i.e., without logging on as an authorized buyer -- and create an
order.  The order should be route-able to a user with purchasing
authorization, who will subsequently assign an MIT account number and object
code, and forward the order to the vendor.  This will entail only one level of
routing.>

.sh 2 "Order Returns"


<Not in alpha release.>


<IIf an item must be returned to a vendor, it should be easy to do through
ECAT.  Users should be able to generate a return authorization on-line, enter
all information required to process the return (e.g., reason for return,
whether the user wants a credit or a replacement item, etc.), and receive a
return authorization number.>

.sh 2 "Portability"


It should be possible to reach ECAT from many locations on campus, not just
from one's own office.

.sh 2 "Hard Copy"


There should be an option to print a hard copy of an ECAT order.

.sh 2 "Vendor Customer Service"


For each supplier, ECAT should display an 800-number with the name of the
vendor's MIT representative, and the phone, fax, and e-mail addresses of the
vendor's campus staff.

.chapter "Order Database Features"


Each vendor is required to maintain an "order database", which contains
certain non-secure information about orders placed by users from the MIT
community. The database is private to the vendor and may be implemented as the
user chooses -- the intended functionality however is to provide the MIT
user the ability to have standing orders, access to previous orders\**,

.(f
\** Many orders will be long and complicated, but differ in only a few items
from the last order: the user should be able to be able to initialize the
order form with the items from a previous order. An MIT-based repository for
orders is not possible, since the order forms differ from vendor to
vendor. <E.g.>, bunsen burners don't come in a variety of colors.
.)f
and even visibility into "in-progress" orders. Some of the desired features
are discussed below.

.sh 2 "Email Notification"


<Not in alpha release.>


<Users should have the option of receiving notification via email that an order
has been routed to them for approval, rather than having to log onto ECAT to
scan for pending orders.>

.sh 2 "Order Reference Numbers and Tracking"


An order reference number (also known as a unique order identifier) is
generated for each order. The order should be trackable from
this number from shipment through payment and posting to the user's financial
statement. Users should be able to look up the status of their order using
the reference number.  Reference numbers should be selectable from a popup
list.

.sh 3 "Hold Orders"


If an order is placed on hold, the order status should reflect the nature of
the problem, so that the user can contact the vendor.

.sh 3 "Reference Notes"

<Not in alpha release.>


<Users should be able to add their own reference notes to an order.>

.sh 3 "Order History"


There should be a way for users to review order history easily from within
ECAT.

.sh 3 "Grace Period"


<Not in alpha release.>


<Users should have the option of a brief grace period (60 minutes) in which to
make corrections to an order before the order is sent to the order fulfillment
system.>

.sh 3 "Summary Functions for Order History"


<Not in alpha release.>


<There should be summary functions of order history: standard electronic
reports the user can generate, such as most recent order, total orders for a
specified period of time, and expenditures for the year to date.>

.sh 3 "Problem Resolution"


Users should have the ability to communicate directly with the vendor
electronically about a product, a problem, etc., and receive a reply
electronically.

.sh 3 "On-line Shipment Tracking"


Users should be able to track shipment information on-line.


<This could be done through Federal Express, although a prerequisite is the
establishment of the appropriate business relationships between Federal Express,
MIT, and the various vendors.>

.sh 3 "Out-of-stock Notification"


Users should be notified when the order is placed that an item is out of
stock. The catalog should contain up to date availability information.

.chapter "Index Database"


The user should not have to know which vendor sells a particular item.  For
example, if a user wants to order tissue wipes, ECAT should be able to
determine which vendor sells that product, and the user should not have to
figure out whether to select the lab supply or office supply catalog.

.chapter "Financial"


Account information is provided by the user as part of the process of filling
out the order. This information is not required or interpreted by the helper
application, nor by the transaction daemon, nor by the vendor, nor by American
Express. It is merely passed along as an opaque block of ascii data through
the entire process, until it finally arrives back in MIT accounting. (American
Express is actually the last in the chain, and will be the party to hand off
the account information to MIT accounting.)

.chapter "Performance and Accuracy"

.sh 2 "Accuracy"


100% accuracy is required for users to trust and eventually rely on ECAT.  The
system must recognize that the user is from MIT and display MIT pricing.  MIT
prices and availability information must be up to date; part numbers must be
accurate; etc.

.sh 2 "Performance"


Speed must be equal to or faster than using a paper catalog; overall
performance has to be fast enough to insure acceptance by the MIT community.

.chapter "Security and Authorization"


Security and authorization will be based on Kerberos. This is described in
detail in the <ECAT Architecture> document.


.sh 2 "Pro-Card Verification"


A key issue for the preferred suppliers is to clarify the data flow regarding
Pro-Card verification by American Express, purchase authorization checking by
MIT, and the required data flows between the supplier and American Express.
Definition of the sequence of events in a transaction and the data to be
transmitted between MIT, the supplier, and American Express must occur at an
early stage in order for the suppliers' ECAT development to move forward.

.sh 2 "Ubiquitous Access"


Access to ECAT should be ubiquitous to maximize use of ECAT.  The cost of
network drops, hardware, and on-going fees will be an obstacle to acceptance
of ECAT in some departments.  Focus group attendees were virtually unanimous
in asking "what will it cost?"

.sh 2 "Fail-Safe"


Fail safe: There should be some review of "unusual" orders to prevent shipment
of obviously incorrect orders, e.g., if someone orders 6 pallets of paper
clips instead of 6 boxes.

.sh 2 "Authorization Limits"


The ECAT Implementation Team recommends that authorization limits for accounts
be simplified to three levels only: $1000, $2500, and unlimited. [The MIT ECAT
Implementation Team] believe[s] it would be a mistake to automate the present
system where any dollar amount is allowable.  However, such a broad policy
change would have to be mandated by MIT.

.sh 2 "Routing unnecessary"


The ECAT Implementation Team also believes that if MIT issues a procurement
card to an individual, that individual is authorized to make purchases, and
no other approval is necessary.  Therefore, no invoices should be produced or
routed for approval.

.sh 2 "Documentation, Training, and Support"


The ECAT Implementation Team recommends that the groups who will provide
documentation, training, and helpdesk support for ECAT become involved in the
project in the lab stage, if not earlier.

.chapter "MIT-wide Infrastructure Requirements"


Below are MIT-wide requirements that have been established for development or
acquisition of Information Technology administrative processing resources at
MIT.  The ECAT should adhere to these requirements.

.sh 2 "Minimum required items"


Software must provide support for current MIT authentication process,
utilizing Kerberos Version 5 (as described in the Kerberos V5 Application
library) and an individual will use a single user name to gain access to any
MIT administrative process for which authorization has been granted.


Software must operate on the current MITnet communications protocol (TCP/IP).


Software must support operation on our current desktop systems, Mac (Mac 7.x
OS), Windows (3.x) and UNIX (MOTIF).


Software must provide the capability to encrypt data for transmission of
sensitive information over a network.


Administrative systems must use a client/server model which provides
presentation level support at the desktop and business-processing at the
server.

.sh 2 "Recommended Items"


Applications should have the ability to export data from the system in a
non-proprietary format.


Applications should have the ability to write and access external functions
(e.g., in C).


Applications should support a platform's native look and feel.


Applications should be able to support the current standard servers, which are
DEC Alpha/OSF1 and Sun Solaris.


Relational databases should be SQL-compliant.


For relational databases, applications should use the standard database
technology, which is currently Oracle.


Applications should have the ability to integrate with current infrastructure
components like workflow, transaction monitor, the MIT people and roles
databases, and the MIT data warehouse.

Applications should not require components duplicating the functionality of
current infrastructure components.


Authorization should be based upon the use of Kerberos authenticated user
IDs.


Applications must not rely on authorization checks which are performed solely
on the client, since this makes the application vulnerable to an attacker
using (easily available) tools which directly access the server and/or the
database, thus bypassing the client authorization checks.  Therefore, the
server must securely authenticate the identity of the client, and perform
authorization checks based on this identity on the server.


In an application using three tiered architecture, where the client talks to
the "middleware" server which then talks to the end database server, the
authentication must take place between the client and the middleware server,
and the middleware server must perform the authorization checks.  The end
database server must also be configured so that it will only accept requests
from the middleware server or from privileged system administrators.
Otherwise, clients would be able to bypass the authorization checks and data
consistency checks performed.