1. Purpose

1.1.

The purpose of this document is to define the General Specification
(GS) for all software development within ARRAY Development Corporation.

1.2.

All software developed after August 1, 1997 must conform
to this GS unless otherwise stated in the specification for the application
or module being developed. Where there is a disagreement between this
GS, and the specification for the application or module, the application
or module specification shall take precedence providing the disagreement
is noted in the module specification. For any other exceptions to be
valid, written permission must be obtained from a designated Product Prime
within ARRAY.

2. Corporate References:

References to ARRAY Development (Canada) Inc. in any software or documentation
shall be:

2.1.

In the first instance the reference shall read: "ARRAY Development
(Canada) Inc.".

2.2.

In all subsequent instances, the reference shall read: "ARRAY".

2.3.

References to DeLiberation in any software or documentation
shall always be DeLiberation™ Extranet.

3. General References:

3.1.

Date: All communications with ARRAY, which reference dates,
will conform to ARRAY's standard date format of yyyy-mm-dd. All dates used
by applications will conform to the system/user's standard date setup within
Microsoft Windows.

3.2.

Time: All communications with ARRAY which reference times
will conform to ARRAY's standard time format of HH:MM:SS where HH is hours
in 24 hour day time format. All times used by applications will conform
to the system/user's standard time setup within Microsoft Windows.

4. Application and Module (General)

This section applies to integrated applications, standalone applications,
and modules which may be used in applications.

4.1

All software, applications, modules, and documentation
developed under contract to ARRAY Development (Canada) Inc. are the exclusive
property of ARRAY Development (Canada) Inc.

4.2

All software will be developed for the 32 bit mode Microsoft Windows
NT 4.0 environment.

4.3.

All software which makes use of electronic mail must use
SMTP for the transmission of mail. POP3 should be used for incoming mail

4.4

All software will be written as scripts for Perl 5.X where
appropriate. Microsoft Visual C++ version 5.0 should be used where Perl
5.X is not appropriate.

4.5

All software, documentation, and help files will be maintained
by ARRAY using a software code management system.

All software which requires a user interface shall conform
to both the standard Windows NT 4.0 graphical user interface (GUI), and
the Windows NT command line interface.

4.9.

All basic forms shall be composed of four components:

HTML Documentation.

Basic HTML Forms.

Basic Perl form processing script (might be multi-page).

Sample Database.

4.10.

All GUI windows must, by default, be 640 X 480 pixels in
size, unless the full content of the window can be displayed in a smaller
window.

4.11.

All GUI windows must be scalable. When the information viewed
exceeds the size of window, scroll bars should be used to control the information
visible in the frame.

4.12.

All help files shall conform to standard Windows NT 4.0
help files and libraries.

4.13.

Wherever possible, developers will make use of existing
ARRAY code and modules in developing new applications and modules. The
developer should request from ARRAY whether there is a source code for
existing modules that could be modified for new applications or modules.

4.14.

Modified modules and applications must be backward compatible
to the previous release. Modified modules and applications must pass all
tests defined for the previous release, as well as the tests defined to
validate the new functionality or expanded requirements of the current/new
release.

4.15.

All applications and modules must be delivered in source,
compiled code, and developer build libraries where required.

4.16.

All help files must be delivered in source, Microsoft help
file and help library format.

4.17.

Unless specified in the module specification, all documentation
must be provided in standard ASCII format.

4.18.

Each individual source code file, help file, HTML file and
ASCII file will contain a commented header with the following information
in the order listed below:

Each software module, object, subroutine, procedure and function within
a source code file should have a header containing:

Brief functional description

Description of any special algorithms used

4.20

All software must be delivered with compilation instructions,
which will produce an identical result to the delivered compiled code.
Verification will be made by ARRAY upon receipt of all code.

4.21

All software/documentation/help files must contain the version
number assigned at the initiation of the project. Developers will append
a two digit (.xx) sub release number and increment the sub release number
with each transfer of the files to ARRAY. The developer sub release number
must be stripped upon official release of the software.

4.22

No additional software other than a browser should be required by the
user to run these applications.

5. Application and Module (Naming
Conventions):

5.1.

ARRAY will provide the names of the projects and applications,
and, on occasion, modules that it requires to be developed. Where items
are not so named it will be the responsibility of the developer to create
names for applications, modules, functions, procedures, and variables.

5.2.

It is essential that developers do not use names that conflict
with existing module, application, and global variable definition names.
Developers must reference ARRAY's list of existing names to ensure that
conflicts are not generated.

All variables will be defined within the source code in
alphabetical order by type, and in alphabetical order within types.

6. Application (Specific)

6.1.

All applications must include the project name and version
number, and the application name and version number in the Help About box.

6.2.

All applications must include a Registration menu item under
the Help box that permits the client to register the application using
ARRAY's electronic software distribution control system. Detailed references,
registration information, function calls, verification calls, etc. will
be defined when a product is selected.

6.3.

All applications must be multi-threaded to support concurrent
use.

6.4.

All applications must be delivered with a suite of tests,
results and documentation on how to run the test and reproduce the test
results. The test results must reflect conformance to the application requirements.

6.5.

All applications must be delivered with both Install and
Uninstall options through the Installation Wizard.

6.6.

In the case of a system application, the Uninstall option
must completely remove the application, registry keys, files, directories,
startup folders, etc. from the client system.

6.7.

In the case of a user application, the Uninstall option
must completely remove references to the application, registry keys, files,
directories, startup folders, etc. from the user's environment on the client
system. If the user is the only or last user with the application installed,
the Uninstall option must completely remove all of the above items from
the client system.

6.8.

System applications will enter options in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\ARRAY\ProjectName\Version\ApplicationName\Version.

6.9.

Initial installation of a system application must, wherever
possible, absorb all system and user options as defaults during the installation
process. For example, if an application has a printer setup, during installation
it will set the application printer options to the Windows default printer
options.

6.10.

User applications will enter options in the registry under
HKEY_CURRENT_USER\SOFTWARE\ARRAY\ProjectName\Version\ApplicationName\Version.

6.11.

In both system and user applications, upgrade installations
to an application will "absorb" the options currently set in the previous
version of the application.

6.12.

All applications will be built with allowance for ARRAY's
electronic software distribution control system. Detailed references, function
calls, verification calls, etc. will be defined when a product is selected.

6.13.

All Installation procedures will be designed to incorporate
a registration process for validation by ARRAY's electronic software distribution
control system. Detailed references, registration information, function
calls, verification calls, etc. will be defined when a product is selected.

6.14

An Installation Wizard must be provided to perform the initial software
installation of the module

6.15

The module must be fully operational once the System Administrator
has run the installation wizard.

6.16

Every time a user incurs an application error, an email message will be passed to the the person responsible for maintaining the application. The email address will be application-maintenance@client.com, unless otherwise specified.

6.17

The background colour for each HTML page used by the application will by "#FFFFFF".

6.18

The background colour of each input form used by the application will be "#FFFFEC".

6.19

Each application will have a questionnaire that prompts the user for feedback on the quality and usefulness of the application.

7. Module (Specific)

7.1.

All modules must be re-entrant.

7.2.

All modules that perform data conversion must validate the
input data before conversion and, on validation failure, return a specific
error code indicating the data was invalid.

7.3.

All modules must be accompanied by documentation declaring
the parameters to be passed, the type of data to be passed, the resultant
data to be returned, and a complete list of error codes that could be returned.

7.4.

All module source code must include a separate header file,
or a reference to header file(s), where data types of parameters, returned
data and error return codes are defined (example).