Functional Requirements Status and Plans Christopher Neyman W. M. Keck Observatory Viswa Velur California Institute of Technology Keck NGAO Team Meeting #10 September 17, Robison Laboratory

2 Outline How to find the FRD drafts and other materials Status of AO and laser FRD draft 0.2 Thoughts on long term requirements management Discussion

3 FRD: How to get there (Twiki) Use this Link

4 FRD: one stop “shopping” (Twiki) Links to current supporting documents

5 FRD: AO and laser drafts v0.2 (Twiki) closer to v0.2

6 FRD: AO section status v0.2 Required functionality well documented Specification need work, values are still TBD Traceability needed Who was the source of the requirement? Revision history Approval status (draft, final, approved, pending, dropped) Science → system → function, Numbering scheme: not consistent between documents (ScRD,SRD,FRD) Rational needed Why this requirement is needed What reference material supports it

7 FRD: Laser Guide Star Facility section status v0.2 Laser status –27 pages of requirements –Tried to cover the bits that make NGAO system different from K1/ K2 LGS. –Have received some inputs on the draft. Need more at this point. Required functionality well documented Specification need work, still some TBDs –Needs some work in integrating and cross referencing tables wrt the main FRD. –Other specific requirements that spring up during this phase will need to be added. Traceability Rational needed –The need/source of most requirements is indicated in brackets with italicized text.

8 Total NGAO requirements will be large Still have FRD sections for instruments and science operations tools Preliminary design and detailed design Draft subcontracts from main NGAO requirements Other systems that are smaller in scope –MOSFIRE: ~700 requirements –NGWFC: 342 requirements –MAGIQ: ~300 requirements NGAO detailed requirements estimate AO = 8*NGWFC ~ 2700 LASER= 4*NGWFC ~ 1370 Ops. tools=4*NGWFC= ~1370 Instruments = 3*MOSFIRE ~ 2100 TOTAL ~ 7500 requirements

9 Will we ever need to know the following? The origin of a requirement (backwards trace) Affects of a requirements change, such as the impact on a design, interfaces, and/or subsystems (forward trace) The most important requirements, especially if resources limited The highest risk requirements How a requirement will be tested (inspection, analysis, demonstration, test) (compliance matrix) A requirement has been satisfied (compliance matrix) Requirements that are unaddressed or unassigned

10 Requirements need supporting information The source of the requirement (who nominated it) A unique identifying number for it The rationale for the requirement (why is the requirement needed?) Change history (how has the statement of the requirement changed over the system life?) Traceability (of each requirement to its source) Status (draft, final, approved, pending approval, disapproved) Assigned to (which subsystem or component of the system)

11 Requirements need supporting information Also useful to capture the following: –Its priority (on a scale of one to three) –Its relative cost to implement (low, medium, high) –Its relative difficulty to implement (low, medium, high)

12 Thoughts on requirements management

13

14 To automate or not to automate Group could consider automated tools –Software industry –Database used at Keck NGWFC and MAGIQ –LLNL, JPL, TMT (What do they use?) Better suited to bigger project Choice of process or knowledgeable scientist, engineer Resources limited Thanks for listening: discussion or questions?