Overview
In this activity, the system’s goals and characteristics are defined, including determining the information the system receives as input, produces as output, and how the overall system functions and interacts with the environment, users, and other interfacing systems. This information is first expressed as general goals, and then refined into precise, verifiable requirements by iteratively performing this activity.
Roles and Responsibilities
See parent activity 3.1 Participate In Systems Requirements And Design.
Controls
See parent activity 3.1 Participate In Systems Requirements And Design.
Inputs
The Preliminary Goals Analysis Document which gives details of the project goals. The contents include the project background, vision, project goals hierarchy, and identified constraints [LHB 7122.1, p. B-7].
Any inspected system design materials available from previous iterations of system design activities (see activity 3.1.2 Define System Design).
Procedures
The subactivities performed now can vary widely between projects. Because this activity may be iteratively performed with activity 3.1.2 Define System Design, some system design materials may be reused or be a basis for continuing to perform any of the subactivities.
The system developer should understand that a project may consist of several separate systems, each with its own requirements and design. One common breakdown is separating flight and ground systems. Each system may have its own set of documentation (e.g., requirements, designs), personnel, and management.
The software developer participates in the following subactivities, which are often performed iteratively and/or in parallel. Goals are refined into detailed, verifiable requirements as the interfaces, modes, and scenarios are determined. Interfaces are refined as the scenarios are developed, revealing additional data and information needs. Mode definitions can lead to identifying new commands and situations that impact the system interfaces, and operational scenarios that must be developed, all of which must be captured in the system requirements. The system requirements documentation may take the form of a MIL-STD-498 System/Subsystem Specification (SSS) (see Appendix E).
1) 3.1.1.1 Establish Project Goals and Requirements. In this subactivity, based upon the Preliminary Goals Analysis Document, the systems engineering group defines the project’s technical and scientific goals, and refines them into detailed, verifiable requirements.
2) 3.1.1.2 Define System Interfaces. This subactivity determines and defines the system’s external interfaces. Most space missions are fundamentally concerned with the generation or flow of information. Thus, the system’s interfaces and the information flow between systems is of primary importance.
3) 3.1.1.3 Develop Operational Scenarios. This subactivity determines and defines how the entire system responds to external events and its general functionality.
4) 3.1.1.4 Determine Required System Modes. This subactivity determines and defines the various system modes and how the system transitions between them.
5) 3.1.1.5 Participate in System Requirements Inspection. In this subactivity, the resulting system requirements are inspected and submitted to project-level configuration management (CM).
Outputs
The defined, documented, and inspected system requirements, including the specified requirements, interfaces, scenarios developed, and the required modes and their transitions. These may take the form of a SSS or equivalent systems requirements documentation.