html5-img
1 / 9

Requirements

Requirements. Bryan Butler. Requirements. Development of the M&C transition software follows from requirements documents: M&C (“real-time”); E2e; Operations; Engineering.

madra
Download Presentation

Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Bryan Butler

  2. 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. EVLA M&C Transition Software CDR

  3. 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 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) 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!) EVLA M&C Transition Software CDR

  6. 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) 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. 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 EVLA M&C Transition Software CDR

  9. 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. EVLA M&C Transition Software CDR

More Related