back to page 2

We have set our starting point for the conceptual design stage by stating goals and potential benefits, initial selection criteria, classes of requirements, a design approach, and initial program concept. We now apply the Systems Engineering method from section 1.5 to further develop the design in increasing detail. The reader should bear in mind that a book such as this is a linear presentation of sections and pages, but the actual method is iterative, with the results of later steps feeding back to update earlier results. We will try to indicate when these differences between practice and description happen.


Program Requirements Analysis edit

Until now we have stated what the program is intended to accomplish in very general terms. The requirements analysis step takes these general statements and develops them into more specific and measurable features at the program level. In later stages of design these will be analyzed in more detail and assigned to separate systems and lower level items as System and Design Requirements which their designs attempt to meet. In the process we map the general requirements to the specific ones to make sure all of them will be met. The minimum number of necessary requirements should be defined at each level of a program's development. Excess requirements limit design options and impose extra costs to design for and verify.

It should be noted that setting initial requirements does not mean they are physically possible, economically feasible, or a better choice than what exists now. They merely establish design targets, and later work will establish if they are the correct ones.


Requirements Sources edit

First we identify the sources or inputs to the requirements analysis. These should come from outside the program itself:

  • Program Goals and Benefits - These were stated on page 1 of this section, and come from unmet desires of civilization as a whole, as best we can determine them.
  • Systems Engineering Experience - Past engineering experience in developing complex programs has identified requirement types that often turn out to be necessary. We can use topical literature to identify ones relevant to this program.
  • External Constraints - These are limits imposed by nature or from human causes such as legal requirements.

In addition to the external requirements, we have ones identified or derived internally from the program goals and benefits, design approach, or initial program concept, which are on page 2.


Analysis Process edit

Goals and Benefits - We examined each of the program goals and benefits as stated on page 1, and attempted to write individual statements of what the program will accomplish in terms of objectives, performance, schedule, cost, technical risk, safety, sustainability, and openness. The headings for these categories come from the list of requirement types in Section 1.5. Different programs would result in a different set of such statements. We tried to make the statements specific and have a measurable feature or parameter. In some cases, this is not possible yet and will have to wait until later in the design process. Placeholders are used for the incomplete statements. The result of this examination and a discussion of how each statement is derived becomes part of the initial draft of the Program Requirements in the next section.

Systems Engineering Experience - We next considered general categories of requirements, such as those listed in Section 1.5, to see what might apply to this program. The program is wide scope and long term at this level of analysis. Therefore many requirements that apply at more detailed levels are not relevant yet. One item that came up is the "Life Cycle", ie when would the program end? We included in the discussion under 1.2 that the endpoint is reaching the stated populations with the ability to continue supporting them afterwards. Compliance to laws, regulations, codes, and standards is too specific to apply at this level, as are durability and quality features. By it's nature this program is intended to have a positive impact on community and the environment. At more detailed levels these may become separate requirements. Manufacturing, Test, and Maintenance also apply at detailed levels. Flexibility, Scalability, and Evolution are expected to apply at the location or system level. Interoperation is met at the program level by virtue of the locations being a part of human civilization as a whole. At more detailed levels specific requirements may emerge for this category. The end result is not many new requirements were identified at the program level from this step.

External Constraints - For now, we consider the requirement to function in more difficult environments and distant locations as a sufficient identification of external constraints. For a specific location, such as the Lunar L2 point, the physical environment and legal regime will become inputs to the more detailed requirements.

Internal Program Requirements - Next we look at the classes of requirements identified on page 2 to see if any of these apply. From the "Improving Life on Earth" heading we define the requirement (2.4) for improved quality of life relative to current levels. The "Understanding the Earth" goal is indirectly enabled by inhabiting more difficult environments. When people are able to live in these remote locations, they can more easily study them, and science may be a major "occupation" for the residents. The data requirement (2.5) aids this goal explicitly. The category of "Reducing Space Hazards" is covered by the Population Risk (6.2) requirement, but we are not yet defining specific risks and reduction targets. This requirement also partly addresses moving hazardous research from the "Increasing Biosphere Security" heading. Active measures to increase biosphere security are covered under Survivability (7.2). Measures under the "Expanding Resources" category includes physical, which is dimensional in terms of locations, area, volume, and environmental range. This is covered by the primary program goal (1.1). Material and energy resources are covered by the Resources requirement (2.6). From "Long Term Survival" we added to the Survivability requirement (7.2) to design for depletion of critical resources. The "Increased Choice" heading is covered by the similarly named requirement (1.3). The primary goal (1.1) of widening the range of civilization addresses the "Increased Opportunity" category in the sense of access to unclaimed and under-used locations. The Openness requirements (8.) maintain access to the technology and locations for people outside the program, giving them increased opportunity.

Design Approach - Our next step was to look at our design approach to see if that drives any program requirements. Normally design progresses from requirements to solution, but this is a check to see if our approach feeds back in the other direction. The idea to reduce conventional rocket use is not a program level requirement, it is a design solution for the space part of the program. The program requirement to lower Earth launch cost (4.3) is what will likely drive the use of that idea. This requirement will also drive using reuse/repair/recycling in terms of longer vehicle life. Improved technology (2.3) and surplus resources (2.6) along with other requirements also drive reuse/repair/recycling, as that idea is a general solution to design optimization. For the space part of our program, using the resources of space is another general solution to optimizing the design. The resource requirement (2.6) to have a surplus output will drive using this idea. Building multipurpose facilities is another optimization vs single purpose design for each task. The program scale requirements (1.2) for permanence and size will likely drive using this idea. Along with growth (2.2) it will drive using the idea of modular design. The design approach of incrementally increasing environment range, distance, and performance has already been incorporated into multiple requirements. Thus we find the requirements will tend to use the ideas in our design approach, but the ideas do not force new requirements.

Program Concept - Similarly we check our initial program concept from page 2 to see if any new requirements are identified:

  • Program Description: We identified a need for production, habitation, and transport as basic to civilization, but these will be developed as lower level functions for each location rather than top level requirements for the program. The top level is covered by the requirement to support a certain number of people (1.2). Set up and expansion of these functions is covered by (2.2) Growth. The main program goal (1.1) is to move to more difficult and remote locations. This will drive remote operations and automation, because humans can't live there until habitats are in place. Resource extraction is explicitly included as a requirement (2.6). Specific Earth or Space location are not identified as program requirements, but are implicit in number of locations (2.1).
  • Seed Factories: The idea of using factory output to expand itself is a good solution to address the Growth (2.2) and Improved Technology (2.3) requirements, but does not impose new requirements at the program level. Technical details of such factories and what they produce would be lower level design and requirements.
  • Cyclic Systems: The idea of using cyclic flows as much as possible is also a good solution to meet many of the program requirements, such as 7. Sustainability and 4. Cost, but we do not see new top level requirements from this idea.
  • High Efficiency Transport: Again, this is a good idea for cost and efficiency reasons. We have set an Earth Launch Cost requirement (4.3) which will direct how hard we work to include this idea. The challenging cost target will tend to force reduction of chemical rocket use as a solution, but this does not impose new top level requirements.

For now, this completes our analysis process. As with any engineering design, more detailed work later on may cause an update to these results.


Initial Draft of Program Requirements edit

The following requirements list is a first draft drawn from the process described in the previous section. The individual requirements are sorted by category and numbered for ease of tracking, with a discussion of how they were developed. Further conceptual design work will add to and refine this list to produce a final Program Requirements Document, one of the outputs of the Conceptual Design stage of a program.

1. Objectives edit

  • 1.1 Program Goal - The program shall expand human civilization to a series of new locations with increasingly difficult environments and distance.

Discussion: Our program concept is to develop new locations starting with the easiest, but with improved technologies in areas like energy, automation, and recycling. This should result in lower costs and improved quality of life measures. This first requirement is just restating the first part of the concept as a definite objective. It is quantified and refined by all the following requirements. Note that new locations include difficult ones on Earth as well as in space.

  • 1.2 Program Scale - Expansion shall be demonstrated by permanently supporting at least 95,000 humans total among new Earth locations and at least 2,000 humans per new space location.

Discussion: A target size is needed to know when you have reached the program goal, and to determine the size of hardware designs. They are intended to be large enough to prove the new locations are permanently occupied and the new technologies function reliably. They are end-point targets for this program, but nothing would prevent further expansion afterwards, or in parallel by other programs. Life cycle analysis ends at this point, but the locations are designed to continue operating. The initial numbers of people will be much smaller, possibly zero if robotic and remote operation is the best way to begin building in space. As a starting point the numbers were arbitrarily chosen to be the square- and cube-root of total human population in 2050. Later sizing analyses will likely change them, but something is needed for the first round of design work.

Demonstration of the new locations and meeting all the other requirements supports the benefit of optimism for the future. It provides an understandable path to an growing, open, and improved life, rather than a finite, closed, and zero-sum world.

  • 1.3 Choice - Specific locations and their internal organization, function, and operation shall be chosen by program participants and location residents within the limits of design constraints.

Discussion: This requirement is included to implement the goal of increased choice and freedom. Therefore choices such as where to build a new location are not imposed from above, but made internally. Participants are people like the designers, who may not end up living in the new location, and residents are the ones that do. Constraints are limits on a design imposed by nature, like level of sunlight at a location, or by humans, such as a law which prevents using fission reactors for power at a given location.

2. Performance edit

  • 2.1 Number of Locations - The design shall maximize the number of new locations, where new is defined by at least a 10% increase in an environment parameter or distance measured in time or energy terms.

Discussion: Requirements can be a fixed number or a variable parameter. Here it is a variable denoted by "maximize" without a specific number. A requirement which can increase without limit results in an unbalanced or infeasible design. So desirable parameters like "more locations" are balanced against the others by using measures of effectiveness and scoring across the entire program. The second part of the requirement establishes how much difference is enough to be new in terms of location.

  • 2.2 Growth - Each location shall increase the capacity for production, habitation, and transport in a progressive manner.

Discussion: Our initial program concept identifies these as basic functions of civilization. Setting a requirement to grow rather than meet a given level all at once allows incremental and modular design. The growth rate and target capacities for each function are not specified at this point. Later modeling and optimization will determine what is feasible, and specific values will then be applied to selected locations.

  • 2.3 Improved Technology - Locations shall increase the levels of self-production, cyclic flows, and autonomy in a progressive manner.

Discussion: The program concept is not just to expand to new locations, but to improve technology levels. This requirement sets the main categories of improvement. It is in terms of all locations as a group, since one location may be dedicated to a single task like mining or growing food. Different locations then trade outputs. The choice of what to do at each location and how much transport is needed between them is a design optimization to be settled later. Self-production is the amount done internally rather than obtained from outside sources. Cyclic flows are materials which get recycled and reprocessed, rather than new inputs and waste outputs. Cyclic flows do not count new production for internal growth or external delivery. Autonomy measures levels of automation and internal control so that a location does not require as much outside support or human labor to keep operating. The numeric levels for these parameters will be set later by what is feasible.

  • 2.4 Improved Quality of Life - Completed locations shall provide an improved physical and social quality of life relative to the upper 10% of Earth civilization.

Discussion: This makes specific the goal of improving life on Earth by demonstrating quality of life well above the current average. The exact measures to compare to will need to be defined later in the concept development. The 10% threshold is a notional goal, representing "better than most" conditions.

  • 2.5 Data - The program shall collect and disseminate [TBD] data about the Earth's environment, surrounding space, and objects therein.

Discussion: This requirement supports the program goal of understanding the Earth better by looking at its environment, and the history and evolution of other planets and objects. We don't know at this stage of the analysis what kinds of data will be useful, at what level of detail, or at what cost, so we use a placeholder value. Existing astronomy and planetary science program are already doing this task, so the final requirements will be in terms of what capabilities beyond that the program will add. In addition, some of the data collection is needed to support future expansion to new locations in space.

  • 2.6 Resources - The program shall output a life cycle surplus of at least 100% of internal material and energy resource needs.

Discussion: - This supports the program goal of expanding the material and energy resources of civilization. The program will consume resources internally to operate, and will not produce a surplus immediately, so this requirement sets a net output requirement for the total life of the program back to civilization.

3. Time edit

  • 3.1 Completion Time - The expansion to a new location shall be completed before expected progress in technology indicates a re-design is required.

Discussion: If the program is too slow to develop a new location, then re-design to account for new technology would be indicated before you are finished, and therefore previous design work is wasted. This is separate from economic or other reasons which might indicate a particular schedule. In case of multiple requirements driving one parameter, the strictest one is used.

  • 3.2 Operating Life - Locations shall be designed for an indefinite life, with maintenance, repair, and replacement.

Discussion: Expansion of civilization is an open ended process, so the intent is to set up permanent new locations. Anything made by humans eventually wears out, breaks, or could be replaced by something better. To reach an indefinite life, then we need to provide for ongoing maintenance, repair of failed items, and eventual replacement or upgrade.

4. Cost edit

  • 4.1 Total Development Cost - The total development cost for new technology and hardware designs shall be less than 50 times the unit cost on Earth, and 5 times the unit cost in space of the hardware.

Discussion: There are only a small number of governments and businesses capable and motivated to do large space projects. A reduced scale, especially in the earlier stages, means more possible entities that could perform the projects, and thus more chances it actually gets done. Large entities are not excluded from these kind of projects, they just should not the only ones able to do them. This is one reason to limit the total development cost. Another is to generate an economic rate of return so the program can pay for itself (or at least pay part of its way). We set reasonable values of 50 and 5 times the unit cost of hardware for Earth and space based on an estimate of the number of locations the hardware will be used, and the desire to keep the development cost reasonable in relation to unit production cost.

  • 4.2 New Location Cost - The peak net project cost for a new location shall be less than 50% of the expected long term net output.

Discussion: For a new program to be justified over doing nothing or continuing with existing programs it must show some benefit or improvement. This requirement sets a minimum benefit in purely economic terms that the life cycle output be worth twice the peak project cost. There are other types of benefits than monetary ones, which would be covered by other requirements, and more detailed cost goals will be worked out in later stages of design.

  • 4.3 Earth Launch Cost - The program shall progressively lower the Earth launch cost component of total system cost, with a goal of $0.08/kg of total system mass.

Discussion: One of the potential program benefits is dramatically lower costs for space projects. We include this as a requirement in order to drive the design to explicitly attempt to reach it. This only addresses the space transport part of the program, Earth surface transport for terrestrial locations is already well optimized, and any program requirement to lower it would be separate and a much smaller goal. Assuming local resources are used in space, a reasonable long term goal is for 2% of total mass to come from Earth. Therefore the goal for the launched mass would $4/kg. The product of the two factors results in Earth launch cost, so the component requirements are inversely related. This is a long term goal, and will not be reached in early parts of the program. Total system mass includes consumed mass like propellants, so propellant production may reach very low percentage launched from Earth fairly easily.

The combination of improved technology (2.3), surplus resources (2.5) and this requirement supports the program benefit of expanded markets.

5. Technical Risk edit

  • 5.1 Risk Allowances - Program designs shall include allowances for uncertainties and unknowns in knowledge, performance, failure rates, and other technical parameters. New designs with higher risk can be included in program plans, but a process shall be included to resolve the risk, and an alternate design with lower risk maintained until resolved.

Discussion: Note that technical risk comes from design unknowns, and is distinct from accident risk. The program goal is to develop new locations with more difficult environments using new technology. The nature of pushing boundaries like this means that a reasonably large level of technical risk will be encountered at first. This does not mean taking risk for it's own sake - there should be sufficient potential gain to justify the higher risk. We adopt an allowance method to manage the technical risk, meaning we estimate the uncertainties and include them in our design. Rather than passively carry the risk, we have added requirements to reduce the risk by methods like testing, and carry a design alternative as a backup if the new technology turns out not to work as desired. The alternative to managing risk it to be safe and conservative, but that does not lead to progress.

6. Safety edit

  • 6.1 New Location Risk - New locations shall progressively lower internal risks to life and property, with a goal of significantly lower risk than the general population.

Discussion: Expanding to new and difficult environments will inherently involve some risk. It is acceptable to have higher than average risk at first. Many people willingly accept such risks if they know about them. This requirement sets a goal that once a location is fully developed, it should be relatively safe for the people and property internal to the location.

  • 6.2 Population Risk - The program shall significantly reduce natural and human-made risks to the general population, including external risks created by the program.

Discussion: There already exist natural risks such as solar flares and asteroid impacts, and human-made risks from orbital debris and launch accidents. These are hazards to society in general. To meet the program goal of reducing hazards from space we set this requirement to reduce them. The program itself will create some new hazards and risks to people and places outside itself. The goal is to reduce the total, including the newly created ones.

7. Sustainability edit

  • 7.1 Biosphere Security - The program shall increase biosphere security by establishing alternate biospheres and long term storage of biological materials.

Discussion: All life on Earth and human civilization currently depends on the single natural biosphere. This is a potential single point of failure from natural or human-made causes. Having a backup in the form of additional functioning biospheres and storage increases security. The habitation requirements under Performance could be met entirely mechanically, so this requirement adds biological features. We cannot reasonably duplicate the entire Earth, so the scope of this requirement will be set by what is feasible.

  • 7.2 Survivability - The program shall design for the long term survival of life and humanity from changes to the Earth which will render it uninhabitable and depletion of critical resources.

Discussion: It is well known that the Sun will get hotter and eventually become a red giant. There may be other long term changes, such as to the Earth's orbit. This requirement sets in place design features that will enable reacting to those long term changes. Because they are far in the future, it may not require much action in the near term beyond understanding what the nature of those changes will be. Critical resources are ones necessary for civilization to function and have limited sources and will run out at some point. Part of the design is to consider what these are and look for alternatives or additional sources.

8. Openness edit

  • 8.1 Open Design - Technology and design methods developed within the program shall be open for others to use. Specific instances of a design and produced items may be proprietary.

Discussion: The combination of developing Earth locations first(1.2 and 2.1 above), improved technology (2.3) and this requirement are aimed at the benefit of technology spin-off/Earth applications. Since they are used on Earth first, and made open, there should be substantial transfer outside the program.

  • 8.2 Access - Development of a new location shall not prevent reasonable access for transit or to unused resources.

Discussion: 8.1 and 8.2 both address the goal of increased opportunity. Opening general technology and methods allows others outside the program to make use of them. Specific designs and artifacts can be proprietary because of the necessity to cover costs. Barriers to entry reduce opportunity, so allowing later arrivals to travel through or access unused resources minimizes those barriers. An example of unreasonable claims would be an exclusion zone extending 1000km from a high orbit platform. Some exclusion zone is reasonable for safety and to prevent sun shading, but not that large.

contine to page 4