1. Requirements
Bryan Butler

2. EVLA M&C Transition Software CDR
Requirements
Development of the M&C transition software follows from requirements documents:
M&C (“real-time”);
E2e;
Operations;
Engineering.
These all incorporate priority and timescale (they are a combination of use cases, requirements, and development plan and thus extremely valuable!);
All available via the EVLA website (computing memos), but all “living documents”;
But remember that we’re only reviewing the transition system here, so only portions of those documents apply (the applicable timescales).
In addition, the requirement to support what is essentially VLA observing provides its own requirements - most of which have not been written down as “requirements” per-se, but are taken directly from operations documents describing standard operating procedures, etc.
2006Dec05/06
EVLA M&C Transition Software CDR

3. EVLA M&C Transition Software CDR
A Note on Notation
The timescales in the requirements documents are like:
Z - now
A - transition
B - prototype correlator
C - shared risk operations
D - full operations
E - “sometime”
Two notes about these timescales:
They do not correspond to the A-E “releases” for the overall division
The actual dates float, so have changed significantly over the past 3 years, as these documents have been developed
2006Dec05/06
EVLA M&C Transition Software CDR

4. Real-time Requirements
This is mostly a collection of requirements relevant to the Executor and very directly related subsystems.
Executor:
Must allow for direct submission of scripts
Dynamic scheduling and subarrays need not be supported
Parameters database:
All quantities necessary to observe with the transition system (antenna positions, pointing model, collimation offsets, delays, focus, subreflector, etc., per antenna, band, IF, as needed)
Control Script Language:
Specifications on quantities to be allowed, etc., and language constructs (jython satisfies all of these, but presents other problems)
2006Dec05/06
EVLA M&C Transition Software CDR

5. Real-time Requirements, cont.
CALC:
Executor to call CALC to calculate delays
AMCS:
Must allow for tracking of up to 10 X sidereal sources
CMCS, Data Blanking & Flagging:
No explicit timescale A or B reqs here (though we’ve had to implement them)
Time:
IAT time to be used; times should be specified in absolute start times or durations for scans/subscans (NOTE: we are currently using UTC, and may continue to do this!)
2006Dec05/06
EVLA M&C Transition Software CDR

6. EVLA M&C Transition Software CDR
E2e Requirements
This document is mostly a collection of requirements not relevant to the M&C system, however, it contains a single section with requirements for TelCal (called RTCAT in the document), with requirements on:
Timing (when it gets invoked)
Autophasing
Determination of: antenna location (“baselines”); antenna global pointing model; focus; delay; bandpass; offset pointing; polarization; flux density scale; opacity; and aperture efficiency
Supported source models
Communications pathways
At the time we wrote this requirements document, we did not foresee any of this being needed until timescale C (“shared-risk science observing”, but at that time timescale C was in Q2 2007, and we now realize we need much of this functionality for Modcomp turn-off (mid-2007)
2006Dec05/06
EVLA M&C Transition Software CDR

7. Operations Requirements
This is mostly a collection of requirements relevant to the Operator’s Interface (or OMT). It contains sections on:
Alerts & Logs
Access to monitor data (overlaps with Engineering reqs doc)
Access to visibility data
Access to parameters database
Scheduling of observations
Among others.
2006Dec05/06
EVLA M&C Transition Software CDR

8. Engineering Requirements
This is mostly a collection of requirements relevant to the so-called Device Browser (which can be considered part of the OMT in a sense) and the Monitor Archive Database. It contains sections on:
Accessing individual and multiple devices
Fast Data Dump
Monitor Archive Database:
Quantities to be archived
Rates
Accessibility (including ability to search, etc)
Ability to do relatively complex analysis on archived data
Plotting of any of the quantities - in Device Browser, Archive, or Analysis Tool
2006Dec05/06
EVLA M&C Transition Software CDR

9. EVLA M&C Transition Software CDR
Some Comments on Use
We are not really using these documents in a strict software engineering sense - we are using them primarily as a guide to initial implementation, but then rely much more heavily on direct input from the users (obtained from regular interaction between the users and the programmers). They are extremely valuable for what they are used for, but we don’t get particularly hung up on, for instance, counting numbers of requirements met vs. time as a measure of productivity or completion.
In fact, for some of the subsystems/programs, the development is so far along that it makes little sense to do this anyway - they are programs that are in place and being used regularly, so response to actual bug and feature enhancement requests has replaced development based on requirements.
2006Dec05/06
EVLA M&C Transition Software CDR