Overview of LAT Requirements and Verification Process for Gamma-ray Space Telescope

1. Gamma-ray Large Area Space Telescope GLAST Large Area Telescope LAT Level Verification LAT Level Requirement Review Kickoff Rich Baun Systems Engineering

2. Agenda • Requirement and verification flowdown overview • Test Case review process overview • Requirements responsibilities • Test case review Test & Verification Website http://www-glast.slac.stanford.edu/systemengineering/Verification%20&%20Test/Verification%20and%20Test.htm

3. Requirement & Verification Flowdown

4. Test Case/Reqt Buy-Off Overview

5. Requirement Owner Responsibilities • Know which requirements you are responsible to buy-off • Know where and how your requirements are sold • Determine your requirement type • Functional – Function not impacted by environments, i.e. Commanding • Environmental – Specific to an environment, usually requires analysis of environmental test data (Thermal, Dynamics, EMI) • Performance – Requires trending, not sold until after TV • Determine what sells your requirement • Successful completion of a test? Data collected and checked by a test? Post test analysis of test data? Analysis only? • There are test reports, test logs, configuration files, digi files (if applicable), and recon files (if applicable) available for review • The VCRM identifies what tests sell what reqts • Test case outlines show where and how each test sells reqts • Write an NCR if you find an anomaly • Provide objective evidence that a requirement is sold • You must certify the LAT complies to the requirement • Is analysis and a formal report required to document compliance?

6. How to Report a Requirement sell-off • Report the requirement sell-off to Systems • For reqts not needing a formal report (most requirements) • Send an e-mail with the following information • Requirement number (REQID) or Verification Plan number (VERID) • Date, time, and run number when supporting test case(s) were run • If data was collected from multiple runs, each run must be noted • Worse case test data that supports the reqt was sold (if applicable) • Compliance statement, i.e. the report must state definitively the LAT complies with the requirement • Margin to the requirement must be stated where appropriate • Any NCRs or JIRAs associated with the requirement must be listed • For requirements needing a formal report • Write a Requirements Verification Report (RVR) • See next slide for details • You will be notified if a requirement needs an RVR

7. Requirements Verification Reports • For an agreed to subset of LAT requirements only, not all reqts • Must have an assigned LAT Docs number • Minimum RVR contents • Requirement owner’s name • Requirement source, text, and number • Verification Plan text and number • Supporting test case name and number (if applicable) • Script name(s) used to run test • Date, time, and run number when supporting test case(s) were run • If data was collected from multiple runs, each run must be noted • Compliance statement, i.e. the report must state definitively the LAT complies with the requirement • Margin to the requirement must be stated where appropriate • Supporting documentation of test data, analysis, and results • Deviations from the verification plan and the reasons for the deviations must be stated • Any NCRs or JIRAs associated with the requirement must be listed

8. VCRM Example

9. Test Case to Requirement Owner (1/2)

10. Test Case to Requirement Owner (2/2)