This is a draft document - please send comments, suggestions, and/or corrections to D. Shepherd (dshepher@nrao.edu). Thanks.

Official ALMA Use Cases have been developed by the SSR and are available in ALMA Software Memo 11 (ALMA-SW-0011 "ALMA Software Science Requirements and Use Cases"). The Use Cases in this document are generally high level and provide a good starting point for this discussion. However, for testing purposes, one generally needs more detailed specifications for how data is processed through the system along different observing mode paths. Once a detailed Use Case has been defined for one or more subsystems, one can then develop a Test Case. A Test Case is a subset of a the more general science Use Case that exercises a specific path in the system for the purpose of testing functionality, interfaces, & usability.

Thus, to effectively test the ALMA software subsystems, we need to develop a consistent set of Use Cases that are specifically designed to exercise different observing & operational modes. And, since this is the international ALMA project, we are required to put all Use Cases in a standard HTML format. Given below is a proposed timeline to develop consistent Use Cases and subsystem test plans along with a suggested approach on how to develop a Use Case.

Note: The ALMA Science IPT is developing a document titled: "The ALMA Design Reference Science Plan" in which science-oriented Use Cases are being developed (e.g. proposal coversheets are being prepared for a large number of science projects). The first draft is expected to be complete by 1sep03 with a final document ready by 15oct03.

Proposed timeline:

1. 09jul03 - Use Case guidelines & examples distributed to SSR & subsystem leads.
2. 13aug03 - SSR members & subsystem Leads complete draft Use Cases for their subsystems and send to D. Shepherd to put on the web.
3. 05sep05 - ASAC meeting.
4. 10sep03 - SSR members & subsystem Leads complete draft test plans including:
   • Draft Test Cases (well-defined for R1 testing, less defined for later tests)
   • When tests will be performed.
   • FTE estimates required to support tests.
   See the ALMA Software Test Plan at http://www.aoc.nrao.edu/~dshepher/alma/ (also available on ALMA SiteScape, SSR "Draft Documents") for guidelines about how to develop a test plan.
5. 1oct03 - R1 delivery. Test plan drafts compared, conflicts with resources or time identified, "testers" for immediate tests identified.
6. 01nov03 - Testing begins (ObsPrep subsystem has first scheduled tests in November, first Offline subsystem test scheduled for jan04).

Suggested Approach to Developing Use Cases for Testing Purposes:

1. Review ALMA Software Memo 11 (ALMA-SW-0011). Identify relevant high-level Use Cases for your subsystem.
2. Subsystem Leads and subsystem scientists meet to clearly define processing steps through the software, decisions points, types of data to be processed, and known uncertainties in software requirements or capabilities. Standard observing modes that should be considered are:
   • Single Field Interferometric Observations
   • Single Field, with short-spacings (ACA & single dish)
   • Interferometric Multi-Field Mosaic, no short spacings
   • Interferometric On-the-Fly Mosaic, no short spacings
   • Interferometric Mosaic, with short-spacings (ACA & single dish)
   • Total Power (single dish) Observations (single field & OTF mosaic)
   • Special Observations (e.g. full polarization, astrometry experiments, solar system, solar, pulsar (phased array, gated observations), VLBI (phased array)
   Note: At the time of this writing (jul03), you may not be able to identify processing steps for all possible modes. Think about what you want to test in the next year or two and focus on those Use Cases that will be most relevant to developing subsystem tests in the near future.
3. Go to the web page: http://www.aoc.nrao.edu/~dshepher/alma/usecases
   You can start building a Use Case using the template UseCaseTemplate.html, or easier still, download a similar Use Case from this site and modify the fields to accommodate your subsystem. Help on how to fill out each field is provided in the document UseCaseTemplateDoc.html
4. Once you have drafted a Use Case, sent it to subsystem Lead/ developers for final review. Also, note interfaces to other subsystems (listed in the Use Case as a "Secondary Actor." and identified in the list of "Preconditions" and "Postconditions"). Review corresponding Use Cases from these interface subsystems (if available) to ensure that they are consistent. Resolve any inconsistencies or identify issues at the end of the document.
5. Send completed Use Case(s) to D. Shepherd (dshepher@nrao.edu) to put on the web in the working directory http://www.aoc.nrao.edu/~dshepher/alma/usecases
6. You can now develop Test Cases that gradually increase in complexity until the full Use Case is exercised.