1 / 14

Functional Requirements Discussion at Keck Observatory: NGAO Team Meeting #10

This document summarizes the discussions from the NGAO Team Meeting #10 held on September 17, 2007, at the W. M. Keck Observatory. Key topics include the status of Adaptive Optics (AO) and Laser Functional Requirements Draft (FRD) v0.2, long-term management of requirements, and traceability of system functionalities. Participants reviewed the need for well-documented specifications, the importance of tracking requirement origins, and the overall structure of requirements management. Links to supporting documents and discussions on potential automation tools within the project were also provided.

mina
Télécharger la présentation

Functional Requirements Discussion at Keck Observatory: NGAO Team Meeting #10

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Functional Requirements Status and Plans Christopher Neyman W. M. Keck Observatory Viswa Velur California Institute of Technology Keck NGAO Team Meeting #10 September 17, 2007 012 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 http://www.oir.caltech.edu/twiki_oir/bin/view.cgi/Keck/NGAO/FunctionalRequirements

  5. FRD: AO and laser drafts v0.2 (Twiki) closer to v0.2 closer to v0.2 http://www.oir.caltech.edu/twiki_oir/bin/view.cgi/Keck/NGAO/FunctionalRequirements

  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. 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?

More Related