Focus
On—TMT Observatory Requirements: Top Level, Deep, and Back
Up Again It is customary to visualize the lifecycle of a project with a V-diagram like the one for TMT in Figure 1. During the development phase, the system specifications and designs get more and more detailed before reaching the point where the actual manufacturing or purchasing can start. This process of "digging deeper" into the design is captured by various documents from the high level requirements to system architecture, to subsystem requirements, to conceptual, preliminary, and, eventually, to final design. The integration and test phase, when it is all put together and where the performance is proven, can be imagined as "climbing out" from the detailed depth of the design and fabrication phase by implementing and verifying the system with a progressively wider perspective and scope. The integration and test phase is recorded in its own documentation essential both for the success of the project and later for efficient maintenance. It all flows from a very few core documents: the Science-Based Requirements Document (SRD) and the accompanying Detailed Science Case (DSC), the Observatory Requirements Document (ORD), the Operations Concept Document (OCD), and the Observatory Architecture Document (OAD). The Science-Based Requirement Document declares the strategic objectives of our customer, the astronomy community of the TMT partners. It is the voice of the scientists who will ultimately use the observatory. Our SRD, with its detailed DSC, is the most fundamental document of the project, as it is supposed to be. The Observatory Requirements, Observatory Architecture, and Operations Concept Documents are the project's response to the SRD. The ORD represents the technical objectives the project is committed to deliver for the approved budget. From a systems engineering point of view, the ORD is the collection of the external requirements the observatory shall meet. In contrast, the OAD describes the high level system design, i.e. the project's technical choices to meet these external requirements. While the system architecture is the result of engineering design, it is formalized as a set of binding requirements for the subsystems. The OCD contains the requirements defining science and technical operations of the observatory. Requirements engineering allows the project to consciously design the various lower and deeper layers of requirements resulting in a consistent, well understood, and linked system of requirements. Traceability linking creates a web of interconnections among requirements, where any inconsistency shows up either as a contradiction along the links or as a "childless" or "orphan" requirement. Linking is also a powerful tool for following changes in the requirements and maintaining the consistency of the design process. Figure 2 shows the requirements flow-down for the TMT project, i.e. the logical interconnections between different requirements, interfaces, designs, and test plans. Every requirement statement must satisfy a higher level requirement or interface definition, while every test needs to be designed so that it actually verifies one or more requirements. In order to maintain a stable configuration and guard the integrity of the design process, the core documents (SRD, ORD, OAD, and OCD) are already under formal change control. Any suggested change to these documents is widely disseminated in the project and checked against the current design directions of the entire system and its subsystems, before it is implemented. This process is embodied by the Change Control Board, an advisory group to the Project Manager that includes the Project and Observatory Scientists, the Systems Engineer, as well as the Department Heads and Group Leaders.
Figure 1. V-diagram for the TMT project visualizing the project development and implementation process, as well as the required documentation for the different phases
Figure 2. Requirements flow down through the various system level |
