High Level Requirements

We list below some high level requirements for the system. These requirements are merely intended to provide a guide to the major issues. They are not intended to be specified here at a level that they could be implemented by a developer.

1.

Architecture

(a)

The system will have several operating modes including Phase 1 GO, Phase 1 Archival, and Phase 2.

(b)

The architecture will allow standalone tools to be plug-ins. Tools will to be developed in parallel with the general infrastructure that ties the tools together.

(c)

The architecture should support making the system as sharable as possible for use by other observatories.

2.

RPS2

(a)

The Phase 2 system will contain the major capabilities of RPS2. These include:

i.

display of appropriate choices of parameter values based on proposal contents

ii.

syntax/semantics checks

iii.

feasibility (Trans)

iv.

schedulability (Spike)

v.

proposal report and summary

vi.

submission

(b)

The system will allow the import of information obtained from RPS2 files. Preprocessing of the RPS2 file may be needed.

(c)

The transition to APT will not require any operational changes to the procedures or software used to process submitted proposals in-house.

3.

User Interface

(a)

The system will minimize the user's need to enter information.

(b)

The system will be reasonably straightforward to use, since it is typically used infrequently. Online help features, including a manual, will be provided. But, users should not need to frequently consult the manual to resolve difficulties. Advanced features will be provided for expert users, but not by default.

4.

Saving and Re-Using Data

(a)

Users will be able to save their current session and be able to restart it with access to all previously entered data.

5.

Proposal Development Process

(a)

Users will have considerable flexibility in the process order for developing proposals. For example, targets could be defined either before or after exposures.

(b)

Users will be able to view and update their proposal data in multiple ways. They will be able to choose a convenient manner for themselves. In particular, all interactive tools can be bypassed through direct entry of information.

(c)

The system will provide a means for users to develop a proposal when away from an internet connection (e.g., while at home or on travel). It may be necessary to prefetch certain data and documentation over the internet.

6.

Performance

(a)

Proposal processing will require less time than for RPS2.

(b)

Batch processing steps will be made interactive wherever possible.

(c)

The system will operate efficiently on commonly available computers at modest cost.