Requirements and Interfaces Erik Johansson and Chris Neyman NGAO PD Team Meeting #6 Thursday, March 19, 2009

2 NGAO Systems Engineering Team Team formed in January to address NGAO Systems Engineering issues: Chris N, Peter W, Rich D, Erik J Meet bi-weekly Twiki Page: Keck/NGAO/SystemsEngineeringGroup Issues discussed to date: –Functional requirements review Reorganization of requirements according to PBS Requirements review and change approval process Reorganization of requirements Dealing with TBDs in requirements Team assignments for requirements review –Interfaces How to manage interfaces: N 2 diagrams, database Review of interfaces

3 Requirements Review Functional requirements written and included in materials for NGAO System Design Review held in March Never formally reviewed. The requirements are important: they form the basis for the system design. The purpose of the review is to ensure that we have a complete, accurate, and self-consistent set of requirements describing the system. The requirements will be used during the remaining phases of the design and during the implementation to ensure that the system we deliver will perform as intended.

4 Contour Database We are using the Contour requirements management tool from Jama Software to manage the NGAO requirements. There are ~600 Functional Requirements to manage. Contour gives us the capability to have configuration management control, traceability, and reporting tools. Contour allows collaborative access to the requirements database. Goal is to have all requirements for the NGAO project managed in Contour.

5 Requirements now organized by PBS Originally requirements were organized according to WBS, which was at times confusing. WBS represents work. Requirements describe the system we are designing. The PBS is a numbering system used to describe the system in a detailed hierarchy. Organizing requirements around the PBS is a natural fit. Modified original PBS to put sensors and DMs with the opto-mech system. PBS still needs scrubbing below the third level

6 Review Process Requirements have been divided up into small manageable sets. Two-person team assigned to each set: one Sys Eng team member plus the effort leader for the PBS area, or an NGAO team leader. Three review phases with proposed due dates of 3/31, 4/14 and 4/28 A formal review process has been defined and documented (KAON 638). Erik is contacting all review participants.

7 Review Guidelines Review should be comprehensive, not just a review of existing requirements. For each PBS area: –Is requirement set complete? –Do additional requirements need to be written? –Is additional analysis or work required for a requirement? Label with To Be Determined (TBD) or To Be Resolved (TBR) Notify Sys Eng team Is requirement written clearly, concisely, in complete sentences, using correct English? Are all requirement fields specified correctly? Is the requirement verifiable? –If we cannot verify a requirement through inspection, analysis, demonstration or test, do we really need it? Does requirement need to be split up into multiple requirements? Lots of references on Sys Eng Twiki page: Keck/NGAO/SystemsEngineeringGroup