Defining Requirements

Suggested Reading

A good design is derived from good requirements. The requirements document is “the ‘bible’ of the design and development process” [Akin]. Systems engineers work with stakeholders (typically principal investigators) to generate a clear, unambiguous, numerical list of validated technical requirements that, if achieved, will complete the program. These requirements take into account the baselined stakeholder expectations, baselined concepts of operations, baselined enabling support strategies, and measures of effectiveness. Notice each input is prefaced with baselined, as requirements may evolve in the design process if the requirement is impossible to meet, adheres to overly imposing constraints on the design, or is deemed irrelevant after a design change. Enabling support strategies are the infrastructure or resources needed to “develop, test, produce, operate, or dispose of the end product”. This input is one method of injecting the subsequent product life cycle phases into the design. For your system design, make sure you are adhering to the most conservative requirements in the program life cycle so there will be no surprising redesigns, especially later in the process. Measures of effectiveness are defined by stakeholders to evaluate the project’s success, not only in the spaceflight mission but also through development, and are translated to measures of performance.

The process of generating requirements with the mentioned inputs and outputs is given in the above flow diagram. Before defining requirements, we must define constraints, functional and behavioral expectations. The most stringent constraints are considered first as these constraints typically cannot be changed and/or are non-negotiable for mission success. Softer constraints are derived from elements that are already under design control and help narrow potential design solutions. Other constraints include external and enabling systems that the system must interface within the system’s life cycle. The final considerations for requirements are not constraints but are generated from functional and behavioral expectations. The resulting requirements are a combination of internally (authored by the design team) and externally composed requirements (adhered to by external agencies).

Requirements can be technical or non-technical. Nontechnical requirements may reside at the program or project requirements level, such as human needs for manned space, user intuition in working with a cube satellite kit, or international collaboration when sourcing major components. Allocated technical requirements can be defined as functional requirements (what functions need to be performed to accomplish the objective?), performance requirements (how well does the system need to perform the functions?), and interface requirements (what connections must be made to the system to perform the functions?). Crosscutting technical requirements originate from the nature of the space environment (like radiation, thermal, acoustic, mechanical loads, contamination, radiofrequency), safety, reliability, human factors, and those that originate from the “-ilities” and from Design and Construction (D&C) standards [NASA]. Standards (or program expectations), even within NASA, are not consistent from center to center so make sure you are aware of the specific standards your project must adhere to; Goddard (GSFC), for example, has publicly posted their own General Environmental Verification Standard, specific to GSFC payloads, subsystems, and components and describes methods for implementing those requirements.

A requirement definition is an art form and a science. Appendix C of the NASA systems engineering handbook contains a checklist on how to write good requirements and Appendix E for validating requirements (requirements for requirements). Bad requirements cause misunderstanding and miscommunication between team members, leading to more rework, schedule delays, and overrun budgets. These requirements are used by the stakeholders to establish the absolute minimum expectation of system function and the technical team to work toward meeting the requirements/flowing down the requirements to subsystems or components. For additional information on types of requirements, requirements databases, and the use of technical standards, refer to the NASA Expanded Guidance for Systems Engineering document.

Requirements specifically made for the CubeSat form factor were written by CalPoly SLO [CubeSat Design Specification Rev. 14]. For your convenience, their definition of requirement terms is as follows:

1.6.1 Shall is used to denote requirements that must be met and will need formal verification.

1.6.2 Should is used to denote a strong recommendation or a suggestion to make formal verification of another requirement easier. In many cases, failure to adhere to “should” statements will limit launch opportunities.

1.6.3 Will is used to denote a situation that is going to happen regardless of inputs from the launch vehicle and/or spacecraft developer. “Will” statements serve to indicate events that the spacecraft developers should be prepared for.

1.6.4 Note is used to denote a recommendation or advice meant to aid the CubeSat Developer

Artemis CubeSat Kit Requirements Example

The Artemis CubeSat Kit mission statement is to create 1) a low-cost satellite kit that can be used as a space flight mission, suborbital payload, avionics on a rocket, or as a tabletop data collector and 2) an online course that teaches undergraduates with no prior aerospace engineering experience the fundamentals to designing and building a small satellite. The CubeSat kit’s highest-level program and project requirements are:

Suggested Reading

In the NASA systems engineering handbook, the act of flowing down requirements toward component selection is called the logical decomposition process, shown in Figure 4.3-1. After the system performance requirements are set, the functional and performance requirements of different subsystems (structures, ADCS, etc.) may be derived, as in Figures 4.2-3. An example of how science pointing requirements at the mission level flow down detailed component requirements are shown in Figures 4.2-5.

With the goal in mind, the process to flow down requirements begins by establishing a system architecture model, which partitions the system into subsystem elements and defines relationships between partitioned subsystems. This system architecture is then functionally analyzed to ensure that the partitioned elements when recombined contribute to the whole system as the system requirements intended. Functional analysis “identifies and links system functions, trade studies, interface characteristics, and rationales to requirements, usually based on the ConOps for the system of interest. Three key steps in performing functional analysis are:

1. Translate top-level requirements into functions that should be performed to accomplish the requirements.
2. Decompose and allocate the functions to lower levels of the product breakdown structure.
3. Identify and describe functional and subsystem interfaces.”

The hope is that the subsystems and subsystem relationships are explicitly defined such that each subsystem may be developed separately from the other. The handbook promotes “a creative, recursive, collaborative, and iterative process that combines an excellent understanding of the project’s end objectives and constraints with an equally good knowledge of various potential technical means of delivering the end products”.

For additional information on product breakdown structure and functional analysis techniques, refer to the NASA Expanded Guidance for Systems Engineering document.

Artemis CubeSat Kit Subsystem Requirements Example

For each high-level requirement, more detailed requirements for the CubeSat Kit are given:

   1. The CubeSat kit components shall be rated for Low Earth Orbit operations, with the option of suborbital and tabletop

1.1 The CubeSat kit shall meet the requirements outlined in NASA’s Launch Services Program Level Dispenser CubeSat Requirements Document (LSP-REQ-317.01B)

1.2 The CubeSat kit shall meet the environmental qualification testing requirements outlined in the Program Level Dispenser CubeSat Requirements Document (LSP-REQ-317.01B)

1.3 The CubeSat kit shall use components that are rated for the space environment or components that are tested and proven to be space worthy for at least 18 months

    2. The CubeSat kit shall be low-cost and accessible to universities and private individuals

2.1 The CubeSat kit shall cost less than $5000 USD

2.2 The CubeSat kit shall be commercially accessible through a public domain digital platform (website)

    3. The CubeSat kit shall function as a basic spacecraft with a payload in space.

3.1 The CubeSat power system shall generate power in LEO and provide sufficient power to all other bus components

3.2 The CubeSat thermal system shall verify or regulate that all components are within an acceptable thermally operational range

3.3 The CubeSat ADCS system shall estimate its position to within 100 m and attitude to within 3 degrees

3.4 The CubeSat command and data handling system stores, processes, and routes all data for the predefined kit components while providing margin for the data needs of a variety of undergraduate payload missions

3.5 The CubeSat communications system shall transmit telemetry from LEO

3.6 The CubeSat structure shall be contained within 1U and offer flexibility in mounting components internally

     4.  The CubeSat kit components shall at least include components in educational ground kits

4.1 The kit’s EPS components shall include solar panels, battery, battery sensors, and a distribution (sub)board

4.2 The kit’s thermal components shall include sensors for the temperature sensors for the solar panels, batteries, and other thermally sensitive boards

4.3 The kit’s ADCS components shall include GPS, magnetometer, estimation algorithms, and processing (sub)board.

4.4 The kit’s OBCS components shall include an onboard processing board and memory.

4.5 The kit’s communication components shall include a radio, antenna, and (sub)board.

4.6 The kit’s structure components shall include chassis walls, base plate, cover plate, and board mounting fixtures

4.7 The kit’s software shall include plug-and-play capability for the kit hardware, real-time monitoring and commanding, visuals for numerical fields and plots, and be opensource

4.8 The kit’s ground support equipment shall include components necessary to handle and develop the kit into a CubeSat

4.9 The kit shall include safe assembly and disassembly instructions that are easily accessible online

     5. The CubeSat kit shall include software that is intuitive for undergraduate students

5.1 The CubeSat kit shall be programmable by undergraduate students at the junior level

5.2 The CubeSat kit shall be brought from an open box to visual plots for at least one sensor in at most one hour

      6. The CubeSat kit shall be accompanied by an online course and tutorials for Spacecraft Mission Design

6.1 The CubeSat kit shall include demos and tutorials to step students through from open box to fully functioning satellite

6.2 The CubeSat kit shall include lessons learned and best practice guidance

6.3 The CubeSat kit shall host a forum for engineering and community support

6.4 The CubeSat course shall offer the theory in designing all subsystems in a small satellite

      7. The CubeSat kit shall be tested to meet environmental requirements set forth in NASA GEVS for spaceflight. The end-user will be responsible for doing final flight environmental testing set forth by their launch provider.

7.1 All components shall undergo a vibration test that qualifies them for spaceflight

7.2 Lithium batteries shall undergo vibration and vacuum testing, as detailed in the NanoRacks Battery Test Procedures Document to qualify them for Manned Flight

7.3 All components shall undergo a thermal vacuum test that qualifies them for spaceflight

The hardware components and software are further defined:

Hardware Component Requirements:

3. The CubeSat kit shall function as a basic spacecraft with a payload in space.

3.1 The CubeSat power system shall generate power in LEO and provide sufficient power to all other bus components

3.1.1 The solar panels shall generate a minimum of 2.5W to charge the battery

3.1.2 The power distribution system shall supply sufficient power to all the other subsystems

3.1.3 The battery shall have a capacity of at least 10Wh

3.2 The CubeSat thermal system shall verify or regulate that all components are within an acceptable thermally operational range

3.2.1 All components shall operate between 0 and 50 degrees Celsius

3.2.2 The CubeSat’s estimated thermal profile shall not exceed the 0 to 50 degree Celsius range for an ISS orbit

3.2.3 Heaters and thermal straps shall provide thermal control of the sensitive components

3.3 The CubeSat ADCNS system shall estimate its position and attitude

3.3.1 The ADCNS sensors shall resolve 3DOF attitude to within 3 degrees in LEO

3.3.2 The ADCNS sensors shall resolve 3DOF position to within 100 m in LEO

3.4 The CubeSat command and data handling system stores, processes, and routes all data for the predefined kit components while providing margin for the data needs of a variety of undergraduate payload missions

3.4.1 Define minimum hard drive memory needed for payload and other components

3.4.2 The onboard computer flash memory shall have at least 32kB

3.4.3 The onboard computer CPU shall have a clock speed of at least 16MHz

3.4.4 The onboard computer shall be the centralized computer commanding all daughterboards

3.4.5 The onboard computer shall have at least 1 USB port available

3.5 The CubeSat communications system shall transmit telemetry from LEO

3.5.1 The radio shall transmit detectable telemetry in amateur radio frequency (UHF)

3.5.2 The ground stations shall receive UHF and process true telemetry

3.5.3 The link budget shall have a margin of at least 5 dB

3.6 The CubeSat structure shall be contained within 1U and offer flexibility in mounting components internally

3.6.1 The CubeSat kit structure shall remain inside a 10 x 10 x 11.35 cm +/- 0.1mm volume while undeployed

3.6.2 All four protruding corners on the top and bottom of the main body of the CubeSat shall not exceed a height of 6.75mm, shall have a minimum length and width of 6mm, and shall have a surface area of 6.5mm x 6.5mm, per NASA CLSI requirements

3.6.3 There shall be a minimum of 20mm from the CubeSat surface to the top of the corners along the Z direction per NASA CSLI Requirements

3.6.4 The four edges of the CubeSat along the Z direction shall have a hardness greater than or equal to Rockwell C 65-70 per NASA CSLI Requirements

3.6.5 The overall structure shall withstand 1200N between two XY planes applied in the Z direction, per NASA CSLI Requirements

3.6.6 The maximum mass of the entire CubeSat Kit shall not exceed 1.33kg per NASA CSLI Requirements

3.6.7 The center of gravity shall be within 2cm of its geometric center relative to the Z direction, per NASA CSLI Requirements

3.6.8 The CubeSat kit shall be easy to assemble with the provided instructions

Software Requirements

5. The CubeSat kit shall include software that is intuitive for undergraduate students

5.1 The CubeSat kit shall be programmable by undergraduate students at the junior level

5.1.1 The necessary programming languages shall require little-to-no prior coding experience

5.1.2 Documentation and tutorials shall be detailed and easily accessible

5.1.3 A forum for users looking to overcome issues shall be created

5.2 The CubeSat kit shall be brought from open box to visual plots for at least one sensor in at most one hour

5.2.1 The CubeSat kit shall be provided with pre-installed software

5.2.2 A tutorial shall be provided which details initial steps to test and demonstrate sensor functionality, completable by most students within one hour

5.2.3 A thumb drive with the necessary development tools will be included to minimize setup time

Note that some requirements, especially in the hardware components, have explicit numerical thresholds whereas the software requirements are softer in definition to account for a diversity of users. These softer requirements need more testing and iteration later in the process to properly fulfill the requirements.

Requirements Verification Matrix

A master spreadsheet, called the requirements verification matrix, that “tracks all requirements, sources, status, and documentation” [Akin]. This document “ensures that nothing gets overlooked and everything is done for a purpose”. A template of the requirements verification matrix may be found in the NASA Systems Engineering Handbook Appendices.

---