Technology Nugget: TMT Requirements Engineering
  Scott Roberts

As Yogi Berra once said, "You've got to be very careful if you don't know where you're going, because you might not get there." Indeed, many engineering projects have faltered because their end goal had not been well defined. Requirements engineering is the activity of defining clearly what a system must accomplish, and determining when it has been accomplished. In engineering projects we refer to the final product, in our case the TMT observatory, as the system, and the major components, such as the primary mirror, as the subsystems. By thoroughly defining the desired behavior of the system and subsystems through a set of engineering requirements, we can be sure that our end goal is clear. In addition, by defining the tests we will perform to verify that the system meets its requirements we have a method of finding out when we are "there."

Three of the TMT Foundation Documents form our highest-level engineering description of the observatory. These are the Observatory Requirements, Observatory Architecture, and the Operations Concept documents. The Observatory Requirements Document (ORD) translates our TMT science vision, as described in the Science Requirements Document (SRD), into a set of definitive function and performance statements that must be met in order to achieve our science goals. Our Observatory Architecture Document (OAD) further defines key architectures and highest-level implementation choices that guide the overall observatory design. It also defines budgets that divide top-level performance requirements amongst the subsystems. The Operational Concepts Document (OCD) describes how the observatory will be operated, and imposes additional requirements in order to achieve this. The project relies on these top-level documents to guide the overall design of the observatory. The requirement statements contained within them flow down to further requirements on the 36 observatory subsystems, including the optics, telescope structure, enclosure, instruments, and their associated control and software systems. These documents and their relationships are shown in Figure 1. The subsystem requirements in turn flow down to subassemblies and components, each of which have their own set of requirements. Requirements engineering ensures that the observatory components are appropriately specified such that when they are assembled into the observatory we will meet the top-level performance requirements. We analyze how the requirements flow down from the highest to lowest levels in the system, and look for inconsistencies or missing requirements at the various levels of the system. By recording the traceability or links between requirements when we write them, we can later analyze whether the various levels of requirements are consistent over the entire system. In addition to tracking the thousands of requirements on the observatory, we must also define how the observatory subsystems interconnect. The necessary behavior and interactions among our subsystems are defined in Interface Control Documents (ICDs). The interfaces among our subsystems typically include details of the mechanical, electrical, optical, power, data, and cooling connections. During observatory construction, we need to be able to check that our requirements are being met, first at the component and subsystem level, and then at the integrated system level. This verification exercise consists of a set of tests on the observatory systems at various points throughout the project timeline. We are employing industry standard software tools to manage our requirements, interfaces, and test plans. This software, called DOORS, allows us to record and structure the requirements, interfaces and tests, and record their relationships. It also provides tools that help analyze the traceability within this information. The organization and relationships, called the schema, for our requirements database is shown in Figure 2.

By implementing formal requirements engineering practices, TMT is well positioned to ensure delivery of an observatory that fully accomplishes our science vision. In summary, through requirements engineering we have clearly defined where we are going and we will know when we get there.

Figure 1 - TMT Requirements Document Structure, showing the top level science requirements document, the three system level requirements documents, and the 36 subsystem requirements documents.

Figure 2 - TMT Requirements Engineering Schema, showing the Design Requirements Documents (DRDs), the Interface Control Documents (ICDs), and the Test Plans (shown in green), along with the traceability relationships between these documents.