| NUMBER |
CRITERIA |
DESCRIPTION |
RATING |
| |
ARCHITECTURAL DETAIL |
|
|
| 1 |
Multi-tier |
System must have a multi-tiered Client/Server Architecture |
Essential |
| 2 |
Multi-platform |
System must provide Windows, web browser and text-based clients |
Essential |
| 3 |
Standard DBMS |
Data must be stored in a RDBMS or ODBMS conforming to industry standards, i.e. non-proprietary |
Essential |
| 4 |
Standard WWW |
System must support use of standard WWW servers and browsers |
Essential |
| 5 |
Scaleable |
Each layer of the architecture must be scalable and manageable independently from every other layer |
Essential |
| 6 |
Z39.50 clients |
System should support all Z39.50 compliant clients |
Essential |
| 7 |
Browser Independent |
Browser Clients should run in either a Windows or Mac/OS environment |
Important |
| 8 |
Staff clients |
Staff clients should run in all Windows environments (Win 95+) |
Important |
| 9 |
Distributed |
The architecture should support multiple processors |
Important |
| 10 |
ISO based ILL |
The system should provide tools for ISO 10160/10161 protocols for ILL |
Important |
| 11 |
X12 based EDI |
The system should provide tools for an X12 interface to EDI |
Important |
| 12 |
UNICODE |
The system should provide for multiple national languages through implementation of ISO standard 10646 (UNICODE) |
Important |
| 13 |
ISO based Quality |
The system should conform to the ISO 9000-3 guidelines for the development and support of quality software products. |
Important |
| 14 |
OO interface |
The system should support a distributed object model such as CORBA, IIOP, EJB |
Desirable |
| 15 |
Thin client |
Support for "thin clients" such as the Solaris Sun Ray |
Desirable |
| |
|
|
|
| |
OPERATIONAL DETAIL |
|
|
| 16 |
University ITS supported servers |
Servers must run on a unix platform from either IBM or SUN |
Essential |
| 17 |
University YAD supported clients |
Browsers and staff clients must run on Intel platforms |
Essential |
| 18 |
University LSO supported OS |
Browsers and staff clients must run on Windows NT and Windows 2000 |
Essential |
| 19 |
University supported open system |
Browsers and staff clients should run on LINUX systems and network appliances |
Desirable |
| 20 |
Business Critical reliability |
System must have a reliability factor of 99.99% |
Essential |
| 21 |
Business Critical Availability |
System must operate on a nearly 24X7 basis |
Essential |
| 22 |
Reporting(1) |
System must provide regular reports on the status of all system management and policy files, as well as all profiles, tables, and other parameters that control the system. |
Essential |
| 23 |
Reporting(2) |
Vendor must provide established procedures to report and track application problems as specified in ISO guideline ISO-9000-3 |
Essential |
| 24 |
Scaleable hardware |
System should be designed to run on parallel system |
Important |
| 25 |
Low Maximum response time |
Transaction response time less than 3.0/secs |
Essential |
| 26 |
Low Typical response time |
Transaction response time less than 0.5/secs |
Desirable |
| 27 |
Low Maximum startup time |
Client Initialization time less than 30 seconds (after OS initialization) |
Essential |
| 28 |
Low typical startup time |
Client Initialization time less than 10 seconds (after OS initialization) |
Desirable |
| 29 |
Non disruptive update and reporting (1) |
Batch data loads, indexing and report generation should not require the system to go down |
Important |
| 30 |
Non disruptive update and reporting (2) |
Batch data loads, indexing and report generation should not significantly impact performance |
Important |
| 31 |
Operational documentation |
Vendor must provide documentation for all transactions, batch, and reporting jobs |
Essential |
| 32 |
Recovery |
Vendor must provide recovery procedures for all tasks including batch type and reporting jobs |
Essential |
| 33 |
Fix Distribution |
Vendor must provide established procedures to distribute bug fixes |
Essential |
| 34 |
Upgrade distribution |
Vendor must provide established procedures for release updates and new versions of the application |
Essential |
| 35 |
Customization |
Customization and maintenance tasks of the application like table changes should be performed by a graphical tool |
Important |
| 36 |
Well structured installation |
Clients used to access the system should be easy to install, maintain, and few in number |
Important |
| |
|
|
|
| |
DEVELOPMENTAL DETAIL |
|
|
| 37 |
Access to Source Code |
The system must provide a flexible development environment by providing and maintaining customer access to current source code to facilitate integration of: locally developed applications; third party software; and interoperability with other Yale systems. |
Essential |
| 38 |
ISO 9000 |
The ability to demonstrate quality control over vendors, internal processes, and user support interfaces as defined in ISO 9000, 9001-9003 |
Essential |
| 39 |
Version control |
The system must provide both forward and backward version control of all software components both distributed and under development. |
Essential |
| 40 |
Industry Standard language |
Only modern and current programming languages, operating systems, network and database interfaces, such as ANSI C, C++, Java, and Visual Basic may be used. Any software content consisting of object code only, or developed using non-industry standard programming languages is unacceptable. |
Essential |
| 41 |
Industry Standard Data Interchange |
Must support data access via standard, non-proprietary database and network protocols ODBC, JDBC, SQL92, CORBA, IIOP, RMI, or equivalents as well as IETF approved TCP/IP transfer protocols |
Essential |
| 42 |
Incremental change |
The development environment should accommodate short development cycles and continuous improvement, without the need for frequent wholesale upgrades to remain current. |
Important |
| 43 |
Industry standard IDE |
Access to services should be based on integrated development environments (IDE) provided by IBM, Sun, Microsoft and others |
Important |
| 44 |
Class extensions |
The ability to locally extend or implement common OO class libraries and interfaces |
Important |
| 45 |
XML extensions |
XML, XSL, XHTML, are all preferred methods of abstracting data content from layout and description. |
Important |
| 46 |
Standard scripting tools |
Scripting interfaces, such as Apache CGI and PERL, which work well in the open software environment. |
Important |
| 47 |
Java standard |
Defined by Sun JDK 1.1.3 and above |
Important |
| 48 |
Support for active user development |
Provision of tools / venues / websites for the development and exchange of user developed software |
Important |
| 49 |
Single development language per component |
Multiple development languages within a single component is undesirable except in the context of a clearly defined short term migration effort. |
Desirable |
| 50 |
Enterprise Java Beans |
As defined by Sun Java 2 and above |
Desirable |
| 51 |
JDBC/CORBA/IIOP |
Current Industry standard |
Desirable |
| 52 |
ISO 9000 certificate |
Certification of compliance by ISO |
Desirable |
| |
|
|
|
| |
SECURITY DETAIL |
|
|
| 53 |
TCSEC level C2 design |
System should be able to demonstrate compliance with DoD Trusted Computer System Evaluation Criteria class (C2). |
|
| 54 |
Systems in this class make users individually accountable for their actions through login procedures, auditing of security-relevant events, and resource isolation. The following are minimal requirements for systems assigned this rating: |
Essential |
|
| 55 |
Secure Clients |
System must have secure clients -- private data is encrypted when passed over the network |
Essential |
| 56 |
Encrypted Login |
Login to technical service modules dependent upon userid and password must be encrypted |
Essential |
| 57 |
Log transactions |
Secure transactions must cut a log record that can be used to trace a transaction |
Essential |
| 58 |
No Compromise of trusted subsystems |
System must not use trusted subsystems (e.g. DBMS) in a manner that defeats or compromises the inherent security of the subsystem (e.g. trivial passwords) |
Essential |
| 59 |
Multiple authentication |
Authentication and authorization must be able to be applied to a user or workstation or both |
Important |
| 60 |
Multiple secure domains |
The system should not adversely effect or be effected by proxies, firewalls or other university security infrastructure |
Important |
| 61 |
Secure scripting |
All scripts should be centrally located and protected with wrappers or sbox or equivalent |
Important |
| 62 |
Validate input |
Programs must validate user input |
Important |
| 63 |
Protect server information |
System protects information about site and server host |
Important |
| 64 |
Secure Shell |
Telnet and FTP access to services should be done via SSH2 |
Important |
| 65 |
PKI enabled |
An API into a PKI capability should be available so that certificates can be used for authentication and authorization |
Desirable |
| 66 |
TCSEC C2 certified |
Where possible, systems and subsystems should be TCSEC certified. |
Desirable |