Mark,

 Some of my thoughts/comments interspersed below

>1. I am not sure I see the value in allowing the
>user to turn off implicit physical constraints such
>as the sun and moon restrictions. 
>Also the system should distinguish these from constraints
>explicitly requested by the user (e.g. orientation).

>2. Not all SPIKE absolute constraints are independent.
>In particular guide stars, orientation, and sun avoidance
>are all tied together. Unless we change the computation
>of these constraints we cannot really turn the constraints
>off/on independently.  

This was a misleading picture.  The user can only turn
off constraints which they are allowed to specify in
the proposal.  Basically this a short cut to modifying the
proposal via the proposal editor.  It allows them to disable
the constraints they have already Specified.  The Sun, Moon, 
etc will always be calculated, especially since these are 
constraints which must be satisfied.  They are also health 
and safety issues.


>3. I did not see any performance requirements on the
>system. I believe the system is meant to be run in
>an interactive mode. The runtime of the system would
>have to be sufficient to meet the need for an interactive
>system.

Right now we haven't defined any specific performance 
requirements. Implicitly we want performance to equal or
better what RPS2 does today.  A couple of reasons for this.

- Assumption that most PIs don't run the visit planner but
a couple of times just to check scheduability.  The visit planner
is not the tall pole tool in performance.

- Assumption that not much resources are available to change
Spike to support improvements for performance.  

- Mimimizesthe risk to APT for providing a VP tool.  Only APT has
to be changed, leaves Spike out as a dependency for APT.  Trade 
between schedule/resources and functionality.

- Assumption that the orbit planner is the most heavily used
tool and we are working to improve performance there.

>4. Requirement 3.1.1 states that constraints will be
>computed using the current version of SPIKE. What
>is meant by the current version of SPIKE? The
>version currently in operational? The version
>included in the APT release?

I expect that we will use the same model as we do for RPS2
today.  We will baseline a version of Spike and it will be used
by APT until we baseline another version for use.  

>5. The ability to suggest changes to fix schedulability
>issues is a hard problem. In order to be testable the 
>requirements would need to be expanded for particular cases
>and made mode explicit. 

Absolutely agree.

>6. The requirements might want to acknowledge that the scheduling
>windows are not accurate for fine grain windows. For example,
>I believe that SPIKE does not calculate phase windows when the
>granularity is too small. A related issue is the ability for
>windows to be displayed at ANY granularity.

Agree, maybe we should restrict the amount you can zoom in on
the display to maybe no more detailed than one day?  

>7. Do we still need to support save offset capabilities?

Were they removed from the proposal instructions?  I guess we
could look into that.