Transcript Johansson
Requirements and Interfaces Erik Johansson and Chris Neyman NGAO PD Team Meeting #6 Thursday, March 19, 2009 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: N2 diagrams, database • Review of interfaces 2 Requirements Review • Functional requirements written and included in materials for NGAO System Design Review held in March 2008. • 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. 3 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. 4 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 5 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. Start Two-person team reviews requirement. Determines if requirement or proposed change is needed. Is requirement or change needed? No Requirement status field is changed to “Disapproved” and Requirements Manager is notified. Yes Requirement is referred to Requirements Manager for discussion with Systems Engineering Team and/or Senior Management Done Yes Team members may make revisions, if necessary. Are changes/revisions high-impact? No Each team member adds comment indicating approval. Effort leader changes status field from “Draft” to “Approved” Done 6 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 7