Skip to content

Objective decomposition

Summary. Objective decomposition is how the ADD turns NASA's top-level Moon to Mars Objectives into things programs can build. Objectives are broken into "characteristics and needs", then into use cases and functions, and finally into reference missions, reference elements and concepts of operations. NASA calls this "architecting from the right", one of five principles it set out with the objectives in 2022. The function and use-case IDs used across this wiki (such as FN-H-201 L and UC-T-103 L) are products of this process.

Architect from the right, execute from the left

"NASA adopts two complementary principles to address its complex exploration goals: architect from the right and execute from the left. Architecting from the right means beginning with long-term goals (farthest to the right on a timeline) and working backwards to establish the capabilities required to achieve them. Systems derived from this process execute from the left through established systems engineering processes, moving left to right on the timeline toward maturity" (ADD Rev C, p. 13).

"The Moon to Mars Architecture methodology decomposes the objectives into the capabilities needed to achieve them (architecting from the right). This results in capabilities that NASA programs or partner contributions can fulfill" (ADD Rev C, p. 16).

The five methodology principles (2022 and 2023)

The principle is older than the ADD. The September 2022 Moon to Mars Objectives says the method "is guided by five inter-related principles" (Moon to Mars Objectives, p. 4):

Principle (2022, p. 4) NASA's wording
Objective-based approach "Know your goal up front (the 'what') and create an integrated plan to achieve it."
Architect from the right / execute from the left "Work backwards from the defined goal to establish the complete set of elements that will be required for success." "Execute development of all elements in regular fashion, integrating as you move right according to the established architecture."
Constancy of purpose "Stick with the Plan: once documented, the goal, top-level objectives, and overall plan should be clear and remain consistent over time."
Unity of purpose "Everyone (inside and outside the Agency) should understand and be able to articulate the vision, goals, and objectives."
Enhanced communication & engagement "The lifeblood that drives the reinforcing cycle of the other principles, and promotes political resilience." It also means outreach, collaboration "with international partners, industry, and academia", and engaging the NASA workforce.

The 2023 Strategy and Objectives Development document gives each a page (Strategy and Objectives Development, PDF pp. 14–16):

  • Objective-based approach: "a shift from a capability-based framework to an objective-based framework, in which top-level goals and objectives lead". "In a schedule vernacular, this envisioned long-term goal is how things look all the way to the right on the schedule" (PDF p. 14). The 2022 document draws the contrast: an objectives-based approach "focuses on the big picture, the 'what' and 'why' … before prescribing the 'how' (e.g., a specific launch vehicle, technology, or acquisition approach)" (2022, p. 4).
  • Architect from the right: "the architectural approach starts from the right (the desired end state) and works backward to decompose the goals and objectives into a complete set of elements, systems, subsystems, etc. required to achieve success." Then "element development follows from the left, integrating into the blueprint architecture as development advances." "For the Moon to Mars strategy, the first step in Architecting from the Right was to establish the blueprint vision and identify the goals and top-level objectives to achieve that vision" (PDF pp. 14–15).
  • Constancy of purpose brings "Technical resilience", "Financial resilience" and "Political resilience". "Constancy does not preclude change. … However, recommended changes must undergo the same rigor the original architecture underwent. Changes cannot be arbitrary or non-technical" (PDF p. 15).
  • Unity of purpose: "the strategy must include a structured assessment and adjustment process to the greatest extent practical, based on feedback from the workforce, the public, and stakeholders" (PDF p. 16).
  • Enhanced communication and engagement: the Federated Board drafted the first objectives and used public feedback to refine them (PDF p. 16).

What changed by Rev C (the wiki's comparison). ADD Appendix A.2 names three of the five: "an objective-based approach, architecting from the right and executing from the left, and constancy of purpose" (ADD Rev C, p. 107). Rev C's own definition (p. 13, quoted above) works backwards to "the capabilities required", where the 2022 and 2023 wording works back to "the complete set of elements".

Why, what, how (2023)

The 2023 document frames the whole method as systems engineering in three steps (Strategy and Objectives Development, PDF p. 10):

  • Why: the value proposition, the three pillars (Why Moon to Mars).
  • What: "NASA leadership builds upon the foundational 'why' platform to determine top-level goals and objectives for the human space exploration enterprise. This forms the 'what', and should be: detailed enough to measure success; rigorous enough in development to outline achievable goals, and consistent with the motivation and future trajectory in order to withstand the test of time, technology, and outside influences."
  • How: "after leadership identifies the 'why' and develops the 'what,' the 'how' must be filled in by a responsible organization assigned and empowered to complete this task – something akin to a Program Office. For Moon to Mars at NASA, that responsible organization is the Exploration Systems Development Mission Directorate (ESDMD). ESDMD will flesh out the elements required to achieve the blueprint goals and objectives, conduct trade studies and analyses of alternatives, and build out and gain approval on the architectural wireframe of activities and implementation."

Characteristics and needs, in 2023. "The Moon to Mars systems engineering approach decomposes the blueprint goals and objectives into characteristics and needs necessary to satisfy them. Characteristics and needs are the features and capabilities that the architecture must supply to accomplish the objectives. Using this decomposition, an architecture can be established that is capable of providing those features and activities" (PDF p. 34). Rev C's definition (below) adds that they "identify a problem to be solved, but are not solutions" (the wiki's comparison).

The starting point: objectives

"NASA's Moon to Mars Objectives define the agency's broad, top-level exploration goals; they represent the desired outcomes of the Moon to Mars Architecture. The objectives are agnostic with respect to implementation; they do not specify architectural or operational solutions. Rather, they provide goals to facilitate the architecture development and a means to measure progress" (ADD Rev C, p. 15). The objectives are grouped under ten goals; see Objectives: the ten goals.

Key terms

NASA's definitions (ADD Rev C, p. 17):

Term Definition
Characteristics and needs "Features to satisfy the goals and objectives; statements that drive architecture capability necessary to satisfy the Moon to Mars objectives, and identify a problem to be solved, but are not solutions."
Use cases "Operations that would be executed to produce the desired needs and/or characteristics."
Functions "Actions that an architecture would perform to complete the desired use case."

The steps

All quotations are from ADD Rev C, p. 17.

  1. Characteristics and needs. "The first step in this process is to define the characteristics and needs required to satisfy an objective or a group of objectives." They "translate those outcomes into the features or products of the exploration architecture necessary to produce those outcomes". NASA defines them "in a form that is still neutral to architectural implementation".
  2. Use cases and functions. "Having defined characteristics and needs, NASA decomposes them into specific implementable functions and use cases, actionable features that could be included in the architecture. Functions are services or actions that the exploration architecture would perform. Use cases describe operations that the architecture employs."
  3. Reference missions, elements and concepts of operations. "Finally, NASA develops reference missions that can provide desired functions, as well as reference elements and concepts of operations to fulfil those missions. This is the first phase in the development of architectural solutions; it demonstrates the viability of reference elements, reference missions, and concepts of operations in delivering functions and use cases, providing characteristics and needs, and ultimately satisfying objectives."

The feedback loop. "There is a feedback loop between the decomposition process and the development of new systems: during design and development, programs or projects assess systems to ensure they achieve expected architectural functions. Adjustments during formulation may lead NASA to descope functions/use cases and allocate them to a different system later in the architecture process. NASA continually revisits the mapping of objectives to reference missions, concepts of operations, and systems to ensure objective satisfaction."

The figure on p. 16

The figure "Objective Decomposition Process and Key Terms" (ADD Rev C, p. 16, read from the PDF; the text layer drops it) is captioned "Illustration of the decomposition of objectives using NASA's process of architecting from the right". It has three levels, with arrows running right to left:

Level (as labeled) Boxes
"Agency Level" "Objectives & Goals": "Leadership defines blueprint vision for the Moon to Mars endeavor."
"Strategy and Architecture Office (SAO)": "Architecture" "Organized by segments and sub-architectures in the Architecture Definition Document (ADD) to group similar features and express the progression of capabilities over time." Inside it: "Characteristics & Needs" ("Features, activities, and capabilities necessary to satisfy the goals and objectives"), which feed "Use Cases" (labeled "Segments") and "Functions" (labeled "Sub-architectures").
"Program Level" "Design Reference Missions/ConOps" and "Elements / Requirements", linked to each other by two-way arrows

So the figure pairs use cases with segments and functions with sub-architectures, by label only; it doesn't explain the pairing. The full tables are in Appendix B (below).

Where the full decomposition is

"For detailed information on objective decomposition, consult the tables in Appendix B or the spreadsheets published concurrently with this document" (ADD Rev C, p. 17). Appendix B runs from p. 109 to p. 185: lunar use cases (p. 110) and functions (p. 117), Mars use cases (p. 127) and functions (p. 135), element function mappings (p. 148), and "Unallocated Functions by Use Case" (p. 167) (contents, pp. 6–7).

Where Appendix B is in the wiki:

B.1 adds that "support functions — including power, communications, command and data handling, positioning, navigation, and timing" need not be mapped within every objective; "they are mapped to other objectives that more specifically address the functional area" (p. 109). The B.2 lists give only IDs and titles. The links between them are in the lunar and Mars decomposition spreadsheets.

The lunar spreadsheet (source page) traces 52 objectives to use cases, use cases to functions, and functions to assets, under the labels "HLR" and "FE+":

It skips the characteristics-and-needs step. Use cases map straight to objectives, and the sheets its key lists for "C&Ns" are not in the file (open question 42). The 2024 tables have them (below).

The Mars spreadsheet (source page) traces 46 objectives (every LM and M one) to 148 Mars use cases, and use cases to 263 Mars functions. It has one decomposition, no segment label and no allocation to assets, and it skips the characteristics-and-needs step the same way:

Characteristics and needs in the 2024 tables

The only published characteristics and needs (C&Ns) the wiki holds are in NASA's 2024 Lunar and Mars Objective Mapping Tables, listed with Revision B (2024 lunar table, 2024 Mars table).

  • All four layers. Lunar: 53 objectives → 133 C&Ns → 162 use cases → 206 functions, plus an allocation to assets. Mars: 46 objectives → 115 C&Ns → 113 use cases → 218 functions.
  • What a C&N looks like. An ID like a use case's (CN-T-108 L) and one statement of what the architecture must be able to do, for example CN-T-108 L, "Visit diverse sites of key scientific interest on the lunar surface, including polar and non-polar destinations to address high priority science goals". It serves seven objectives and has two use cases under it.
  • The full lists: Lunar characteristics and needs and Mars characteristics and needs, with the objectives each C&N serves and the use cases under it.
  • Gaps in the chain. 17 lunar C&Ns have no use case ("BLANK"), so two objectives, AS-02 LM and OP-10 LM, reach no lunar use case. On Mars, only the C&Ns of the Transportation and Habitation, Mars Infrastructure and Operations objectives have use cases: "SCIENCE OBJECTIVES HAVE NOT YET BEEN DECOMPOSED FOR MARS UCFS" (the table's own note). Revision C added the Mars science use cases.
  • How 2025 relates. For ten objectives checked, the December 2025 objective–use case links are exactly the 2024 links read through the C&Ns, with the C&N layer removed. That is the wiki's check, not a statement in any source.
  • What isn't known. Whether the 2024 C&Ns are still current. The 2025 keys list C&N sheets the files lack, and Rev C still says its tables trace "through characteristics and needs" (p. 109) (open question 42).

In the executive overviews (2023 and 2024)

The 2023 and 2024 executive overviews, both older than Rev C, explain the method for a general reader. Page numbers are their PDF pages.

  • The #2 pencil. Both print the same box, "Selecting the Right Tools" (2023, PDF p. 4; 2024, PDF p. 25): "Architecting from the right means developing the capabilities and technologies needed to achieve specific long-term goals, not just making decisions arbitrarily or out of short-term convenience. For example, if one needs to write something down, the instinct might be to choose a yellow #2 pencil, but what is the essential function needed? Writing is the use case, being erasable is an operational constraint, and being yellow is a design feature. The #2 pencil meets the need, but a pen, marker, or paint might be just as well suited to the task. Ensuring a full understanding of the needs, constraints, and long-term applications is essential to the decision. In the same way, NASA must consider its objectives and then build the systems to accomplish them, not simply select tools that may already exist. The architecture process enables methodical deliberation to avoid bias, and instead favors the most effective tools." (2023 wording; 2024 drops "the" before "capabilities" and "just" before "making".)
  • Gaps fall out of it. Architecting from the right "identifies technology and capability gaps that NASA must address to achieve the Moon to Mars Objectives" (2023, PDF p. 3).
  • Where the decomposition is kept. "NASA documents the decomposition in a model-based systems engineering environment, where use cases and functions can be further mapped to individual requirements owned by elements' implementing programs" (2024, PDF p. 21).
  • The figure. Both print the p. 16 figure (2023, PDF p. 4, "Illustration of NASA's evolutionary architecture decomposition process"; 2024, PDF p. 21), with the same boxes and texts as the wiki reads them. The 2023 overview adds a worked example, Figure 3, "Example decomposition of two characteristics and needs into their associated use cases and functions" (PDF p. 5): one Transportation and Habitation objective, its characteristics and needs, and the use cases and functions of two of them. Its labels are too small to read at page resolution.
  • Shorter definitions. Their key-terms box words use case, function and characteristics and needs differently from the ADD's; for example a function is "An action necessary to satisfy a use case" (2024, PDF p. 20). All seven terms are compared on the 2024 overview's source page.

The wiki's comparison with Rev C: the ADD has neither the pencil nor "model-based systems engineering" (search of the text); its p. 17 text calls the process's products "reference missions", "reference elements" and "concepts of operations" (above).

In the February 2024 workshop briefing

Two decks from the February 2024 workshops, older than Rev B and Rev C, add numbers and the program level.

Rev A's lunar decomposition in numbers. Pie charts headed "Lunar Objective Decomposition": characteristics and needs 57 unchanged and 174 modified; use cases 18 unchanged, 64 modified, 85 added, 22 removed; functions 20 unchanged, 111 modified, 120 added, 27 removed; and "179 characteristics and needs added for Mars objectives" (Overview and Updates, slide 9, read from the image). By the wiki's sums, Rev A held 231 lunar characteristics and needs, 167 use cases and 251 functions; the 2024 tables hold 133, 162 and 206 (above).

Below the ADD: a requirements flow-down. The Program Office showed how one use case, "UC-001-L Crew and supporting system(s) transit from Earth to cislunar space", reaches program requirements: its seven functions (F-001-L to F-007-L, Rev A's IDs) each map to a capability in "ACD-50007 ConOps Capabilities" (for example "A.6.2 Provide Aborts"), which maps to requirements such as "ACD-R-22 Loss of Crew" or "CESD-R-25 SLS TLI Capability" (Program Office updates, slide 4, transcribed there). It is the only source the wiki holds that fills the figure's "Program Level" boxes, "Design Reference Missions/ConOps" and "Elements / Requirements" (above; the pairing is the wiki's). None of the document families is expanded on the slide.

How the rest of the wiki uses it

  • Moon Base functional gaps. The Users Guide defines functional gaps as "architecture functions that are either currently unallocated to any existing elements, or functions that need additional performance to be fully satisfied" (Users Guide, p. 9). Those are functions in the sense above. See Phase 1 functional gaps.
  • Technology gaps trace to use cases, functions and definition tasks (tech gaps spreadsheet).
  • Data gaps trace to objectives by code, such as LI-07 L (data gaps spreadsheet).
  • What the parts of an ID mean.
    • Function and use-case IDs: the trailing L or M marks the lunar or the Mars list, which "follow independent numbering schema" (p. 109). The letter is read as the sub-architecture. See Use cases and functions and open question 8.
    • Objective codes: the prefix is the goal; the individual lunar objectives are on Lunar objectives. The suffix gives "the applicability to Lunar (L), Martian (M) or both (LM)", as in LI-07 L (Objectives).

Objectives: the ten goals · Lunar objectives · Lunar characteristics and needs · Mars characteristics and needs · Lunar function allocation · Use cases and functions · Lunar use cases · Lunar functions · Architecture framework · Architecture definition process · Why Moon to Mars · Phase 1 functional gaps · Gaps index · Data gaps index

Sources

ADD Rev C, pp. 6–7, 13, 15–17, 107, 109 · Moon to Mars Objectives (2022), p. 4 · Strategy and Objectives Development (2023), PDF pp. 10, 14–16, 34 · Moon Base Users Guide, p. 9 · Lunar objective decomposition spreadsheet, key sheet and mapping sheets · 2023 executive overview, PDF pp. 3–5 · 2024 executive overview, PDF pp. 20–21, 25 · 2024 lunar table and 2024 Mars table, C&N sheets