text:
Reverse Engineering/Cracking Windows XP Passwords

This page is about cracking (recovering) passwords on Windows XP machines, which is a computationally difficult process. If you just need to set a new password (but without need to recover the old one), then this guide is not for you. For that, you can use, for example, the free-software tool Offline NT Password & Registry Editor or other similar programs.

Background
The Windows XP passwords are hashed using LM hash and NTLM hash (passwords of 14 or less characters) or NTLM only (passwords of 15 or more characters). The hashes are stored in. The SAM file is encrypted using  and is locked when Windows is running. This file is a registry hive which is mounted to  when windows is running. The SYSTEM account is the only account which can read this part of the registry. To get the passwords, you need to shutdown Windows, decrypt the SAM file, and then crack the hashes. If everything goes well, you'll have the passwords in 15 minutes.

The hashes can be also obtained from running system using software like pwdump. However, it requires to be run under an account with administrator privileges.

Three ways to recover Windows Password
Usually, we can recover Windows admin password in two traditional ways. The first is to change Screen password with another admin account; the second is to recover the previous password with the windows password reset disk that had been created before you forgot the password. Take Windows XP for example,

 * At the Windows XP login prompt when the password is entered incorrectly click the reset button in the login failed window.

 * Insert the password reset diskette into the computer and click Next.

 * If the correct diskette Windows XP will open a window prompting for the new password you wish to use.

However, we often ignore the importance of security until we have been locked out of computer. Fortunately, there is still the last way that can unlock your computer without reinstalling - erase Windows password with Windows password reset CD, which can recover admin password for Windows 7/XP/Vista/NT/2000/2003.... Take Windows Password unlocker for example, followings are the steps to create the reset CD

 * Download Windows Password Unlocker from Password Unlocker Official site

 * Decompress the Windows password unlocker and note that there is an .ISO image file. Burn the image file onto an blank CD with the burner freely supported by Password Unlocker.

 * Insert the newly created CD into the locked computer and re-boot it from the CD drive.

 * After launched the CD, a window pop up with all your account names(if you have several accounts) select one of the accounts that you have forgotten its password to reset it.

Detailed Instructions for LoginRecovery.com Service

 * Go to http://loginrecovery.com/ and from the home page click the option to download either the floppy disk image or CD image. If you use the floppy disk image, insert a blank floppy disk into your computer, run the program and a bootable floppy will be created.  If you use the CD version, you will need to manually burn the ISO image to a CD, using software which specifically burns ISO images

 * Insert the floppy disk or CD into the target computer from which you wish to extract the passwords. Then boot the computer.  You may need to alter the BIOS settings to ensure the floppy drive or CD is booted from.

 * If you used the floppy drive some messages will briefly appear on the screen and then the computer will shutdown. On the floppy disk will be a newly created file called "upload.txt" which will contain the encrypted passwords.  If you used the CD version, the encrypted passwords will be shown on the screen; write them down into a text file.

 * If you wish to wait up to 48 hours or pay to get your passwords, then you can upload the file onto the LoginRecovery site. Otherwise, continue reading.

 * The file will consist of several 2-line entries, one for each account. Copy the 2 lines for the account you want and paste it into this utility to decode it into the "pwdump" format.

 * Use any of the tools in the following section to decode the pwdump hash.


text:
High School Mathematics Extensions/Supplementary/Differentiation

Differentiate from first principle(otherwise known as differentialisation)
This section and the *differentiation technique* section can be skipped if you are already familiar with calculus/differentiation.

In calculus, differentiation is a very important operation applied to functions of real numbers. To differentiate a function f(x), we simply evaluate the limit
 * $$\lim_{h \to 0}\frac{f(x + h) - f(x)}{h}$$

where the $$\lim_{h \to 0}$$ means that we let h approach 0. However, for now, we can simply think of it as putting h to 0, i.e., letting h = 0 at an appropriate time. There are various notations for the result of differentiation (called the derivative), for example
 * $$f'(x) = \lim_{h \to 0}\frac{f(x + h) - f(x)}{h}$$

and
 * $$ \frac{dy}{dx}= \lim_{h \to 0}\frac{f(x + h) - f(x)}{h}$$

mean the same thing. We say, f'(x) is the derivative of f(x). Differentiation is useful for many purposes, but we shall not discuss why calculus was invented, but rather how we can apply calculus to the study of generating functions.

It should be clear that if $$g(x) = f(x)$$ then $$g^\prime(x) = f^\prime(x)$$ the above law is important. If g(x) a closed-form of f(x), then it is valid to differentiate both sides to obtain a new generating function.

Also if $$h(x) = g(x) + f(x)$$ then
 * $$h^\prime(x) = g^\prime(x) + f^\prime(x)$$

This can be verified by looking at the properties of limits.

Example 1
Differentiate from first principle f(x) where
 * $$f(x) = x^2$$

Firstly, we form the difference quotient
 * $$f^\prime(x) = \lim_{h\to 0}\frac{(x + h)^2 - x^2}{h}$$

We can't set h to 0 to evaluate the limit at this point. Can you see why? We need to expand the quadratic first.
 * $$ = \lim_{h\to 0}\frac{x^2 + 2xh + h^2 - x^2}{h}$$
 * $$ = \lim_{h\to 0}\frac{2xh + h^2}{h}$$

We can now factor out the h to obtain now
 * $$\lim_{h\to 0}2x + h $$

from where we can let h go to zero safely to obtain the derivative, 2x. So
 * $$f^\prime(x) = 2x$$

or equivalently:
 * $$(x^2)' = 2x$$

Example 2
Differentiate from first principles, p(x) = xn.

We start from the difference quotient:
 * $$p'(x)= \lim_{h\to 0}\frac{(x + h)^n - x^n}{h}$$

By the binomial theorem, we have:
 * $$=\lim_{h\to 0} \frac{1}{h}(x^n + nx^{n-1}h + ...+ h^n - x^n)$$

The first xn cancels with the last, to get
 * $$=\lim_{h\to 0} \frac{1}{h}(nx^{n-1}h + ...+ h^n)$$

Now, we bring the constant 1/h inside the brackets
 * $$=\lim_{h\to 0}nx^{n-1} +...+ h^{n-1}$$

and the result falls out:
 * $$=nx^{n-1}$$

Important Result  If

p(x) = x^n $$ then

p'(x) = nx^{n-1} $$

As you can see, differentiate from first principle involves working out the derivative of a function through algebraic manipulation, and for that reason this section is algebraically very difficult.

Example 3
Assume that if
 * $$h(x) = f(x) + g(x)$$

then
 * $$h^\prime(x) = f^\prime(x) + g'(x)$$

Differentiate $$ x^2 + x^5 $$

 Solution  Let $$h(x) = x^2 + x^5$$
 * $$h'(x) = 2x + 5x^4$$

Example 4
Show that if
 * $$g(x) = Af(x) then$$
 * $$g^\prime(x) = Af^\prime(x)$$

 Solution

\begin{matrix} g(x) &=& Af(x)\\ \\ g'(x) &=& \lim_{h\to 0}\frac{A}{h}(f(x + h) - f(x))\\ \\     &=& A\lim_{h\to 0}\frac{1}{h}(f(x + h) - f(x))\\ \\     &=& Af'(x) \end{matrix} $$

Example 5
Differentiate from first principle

\begin{matrix} f(x) = \frac{1}{1-x} \end{matrix} $$

 Solution

\begin{matrix} f'(x) &=& \lim_{h\to 0}\frac{1}{h}(\frac{1}{1-(x+h)} - \frac{1}{1-x})\\ \\     &=& \lim_{h\to 0}\frac{1}{h}(\frac{1 - x - (1 - (x+h))}{(1-(x+h))(1-x)})\\ \\     &=& \lim_{h\to 0}\frac{1}{h}(\frac{h}{(1-(x+h))(1-x)})\\ \\     &=& \lim_{h\to 0}\frac{1}{(1-(x+h))(1-x)}\\ \\     &=& \frac{1}{(1-x)^2} \end{matrix} $$

Exercises
1. Differentiate
 * $$f(z) = z^2$$

2. Differentiate
 * $$f(z) = (1 - z)^2$$

3. Differentiate from first principle
 * $$f(z) = \frac{1} {(1 - z)^2}$$

4. Differentiate
 * $$f(z) = (1 - z)^3$$

5. Prove the result assumed in example 3 above, i.e. if
 * f(x)=g(x)+h(x)

then
 * f′(x)=g′(x)+h′(x).

Hint: use limits.

Differentiating f(z) = (1 - z)^n
We aim to derive a vital result in this section, namely, to derive the derivative of
 * $$f(z) = (1 - z)^n $$

where n ≥ 1 and n an integer. We will show a number of ways to arrive at the result.

Derivation 1
Let's proceed:
 * $$f(z) = (1 - z)^n$$

expand the right hand side using binomial expansion
 * $$f(z)

= 1 - {n \choose 1}z + {n \choose 2}z^2 + ... + (-1)^nz^n$$ differentiate both sides
 * $$f'(z)

= - {n \choose 1} + {n \choose 2}2z + ... + (-1)^nnz^{n-1}$$ now we use $${n\choose i} = \frac{n!}{i!(n-i)!}$$
 * $$f'(z)

= - \frac{n!}{1!(n-1)!} + \frac{n!}{2!(n-2)!}2z + ... + (-1)^nnz^{n-1}$$ and there are some cancelling
 * $$f'(z)

= - \frac{n!}{1!(n-1)!} + \frac{n!}{1!(n-2)!}z + ... + (-1)^nnz^{n-1}$$ take out a common factor of -n, and recall that 1! = 0! = 1 we get
 * $$f'(z)

=-n(1 + \frac{n-1!}{1!(n-2)!}z + ... + (-1)^{n-1}z^{n-1})$$ let j = i - 1, we get
 * $$f'(z)

=-n(1 + \frac{n-1!}{1!(n-2)!}z + ... + (-1)^{n-1}z^{n-1})$$ but this is just the expansion of (1 - z)n-1
 * $$f'(z) = -n(1 - z)^{n-1}$$

Derivation 2
Similar to Derivation 1, we use instead the definition of a derivative:
 * $$f'(z) = \lim_{h \to 0}\frac{(1 - (z+h))^n - (1-z)^n}{h}$$

expand using the binomial theorem
 * $$f'(z) = \lim_{h \to 0}\frac{\sum_{i=0}^n{n \choose i}(-1)^i(z+h)^i - \sum_{i=0}^n{n \choose i}(-1)^iz^i}{h}$$

factorise
 * $$f'(z) = \lim_{h \to 0}\frac{\sum_{i=0}^n{n \choose i}(-1)^i((z+h)^i - z^i)}{h}$$

take the limit inside (recall that [Af(x)]' = Af'(x) )
 * $$f'(z) = \sum_{i=0}^n{n \choose i}(-1)^i\lim_{h \to 0}\frac{(z+h)^i - z^i}{h}$$

the inside is just the derivative of zi
 * $$f'(z) = \sum_{i=1}^n{n \choose i}(-1)^iiz^{i-1}$$

exactly as derivation 1, we get
 * $$f'(z) = -n(1-z)^{n-1}$$

 Example  Differentiate (1 - z)2

 Solution 1
 * f(z) = (1 - z)2 = 1 - 2z + z2
 * f'(z) = - 2 + 2z
 * f'(z) = - 2(1 - z)

 Solution 2 By the result derived above we have
 * f'(z) = -2(1 - z)2 - 1 = -2(1 - z)

Exercises
Imitate the method used above or otherwise, differentiate:

1. (1 - z)3

2. (1 + z)2

3. (1 + z)3

4. (Harder) 1/(1 - z)3 (Hint: Use definition of derivative)

Differentiation technique
We will teach how to differentiate functions of this form:
 * $$f(z) = \frac{1} {g(z)}$$

i.e. functions whose reciprocals are also functions. We proceed, by the definition of differentiation:
 * $$f(z) = \frac{1} {g(z)}$$

\begin{matrix} f'(z) &=& \lim_{h\to 0}\frac{1}{h} (\frac{1} {g(z+h)}  - \frac{1} {g(z)})\\ \\     &=& \lim_{h\to 0}\frac{1}{h} (\frac{g(z) - g(z+h)} {g(z+h)g(z)}) \\ \\     &=& \lim_{h\to 0}\frac{g(z+h) - g(z)}{h} \frac{-1} {g(z+h)g(z)} \\ \\     &=& \lim_{h\to 0} g'(z) \frac{-1} {g(z+h)g(z)}\\ \\     &=& -\frac{g'(z)} {g(z)^2}\\ \end{matrix} $$

Example 1

\begin{matrix} \frac{1}{1-z} & = & 1 +& z + z^2 + z^3 + ... \\ \\ (\frac{1}{1-z})' & = &   & 1 + 2z  + 3z^2 + ... \\ \end{matrix} $$ by
 * $$ (\frac{1}{g})' = \frac{-g'}{g^2}$$

where g is a function of z, we get

\begin{matrix} \frac{1}{(1-z)^2} & = &   & 1 + 2z  + 3z^2 + ... \\ \end{matrix} $$ which confirmed the result derived using a counting argument.

Exercises
Differentiate

1. 1/(1-z)2

2. 1/(1-z)3

3. 1/(1+z)3

4. Show that (1/(1 - z)n)' = n/(1-z)n+1

Differentiation applied to generating functions
Now that we are familiar with differentiation from first principle, we should consider:
 * $$f(z) = \frac{1} {1 - x^2}$$

we know
 * $$\frac{1} {1 - x^2} = 1 + x^2 + x^4 + x^6 + ....$$

differentiate both sides
 * $$\begin{pmatrix}\frac{1} {1 - x^2}\end{pmatrix}' = 2x + 4x^3 + 6x^5 + ....$$

 * $$\frac{2x} {(1 - x^2)^2} = 2x(1 + 2x^2 + 3x^4 + ....)$$

therefore we can conclude that
 * $$\frac{1} {(1 - x^2)^2} = 1 + 2x^2 + 3x^4 + ....$$

Note that we can obtain the above result by the substitution method as well,
 * $$\frac{1} {(1 - z)^2} = 1 + 2z + 3z^2 + ....$$

letting z = x2 gives you the require result.

The above example demonstrated that we need not concern ourselves with difficult differentiations. Rather, to get the results the easy way, we need only to differentiate the basic forms and apply the substitution method. By basic forms we mean generating functions of the form:
 * $$\frac{1}{(1-z)^n}$$

for n ≥ 1.

Let's consider the number of solutions to
 * $$a_1 + a_2 + a_3 + ... + a_n = m$$

for ai ≥ 0 for i = 1, 2, ... n.

We know that for any m, the number of solutions is the coefficient to:
 * $$(1 + x + x^2 + ...)^n = \frac{1}{(1 - z)^n}$$

as discussed before.

We start from:
 * $$\frac{1}{1 - z} = 1 + x + x^2 + ... + x^n + ...$$

differentiate both sides (note that 1 = 1!)
 * $$\frac{1!}{(1 - z)^2} = 1 + 2x + 3x^2... + nx^{n-1} + ...$$

differentiate again
 * $$\frac{2!}{(1 - z)^3} = 2 + 2\times 3x... + n(n-1)x^{n-2} + ...$$

and so on for (n-1) times
 * $$\frac{(n-1)!}{(1 - z)^n} = (n - 1)! + \frac{n!}{1!}x + \frac{(n + 1)!}{2!}x^2 + \frac{(n + 2)!}{3!}x^3 + ...$$

divide both sides by (n-1)!
 * $$\frac{1}{(1 - z)^n} = 1 + \frac{n!}{(n-1)!1!}x + \frac{(n + 1)!}{(n-1)!2!}x^2 + \frac{(n + 2)!}{(n-1)!3!}x^3 + ...$$

the above confirms the result derived using a counting argument.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
User talk:59.144.59.198

Please stop adding nonsense to Wikibooks. It is considered vandalism. If you would like to experiment, use the sandbox. Thank you.

title: User talk:59.144.59.198


text:
User:Crcarter

I may or may not have a philosphy on food. If I do and I were to verbalize it, it might be something like "I'd rather know what I'm doing than I would to just do it." Cooking by rote does not interest me.

I tend to focus on locally available, minimally processed ingredients as these are the very same foods that led our forebears to create the great cuisines.

My favorite cook books (and books on food):

 * Everything by John Thorne
 * Outlaw Cook (ISBN 0865474796)
 * Serious Pig (ISBN 0-86547-597-0)
 * Pot on the Fire (ISBN 0865476209)
 * On Food and Cooking by Harold McGee (ISBN 0684800012)

title: User:Crcarter


text:
Japanese/Reader/第三夜

This story was written by Natsume Soseki (夏目漱石), as part of the 10 nights of dreams. This is the third story, called the third night.

Contents

 * Part 1
 * Part 2
 * Part 3
 * Part 4
 * Part 5
 * Part 6
 * Part 7
 * Part 8
 * Part 9
 * Part 10
 * Part 11

title: Japanese/Reader/第三夜


text:
Cookbook talk:Potato Soup

Simplification
Does this soup have a particular lineage? Is it a traditional soup of a particular cuisine? When I think potato soup, I certainly don't think about carrots, flour and boullion; all of which seem to cover up the "potato-ness" of the soup. Clayton Carter 13:30, 30 October 2005 (UTC)

Isn't there supposed to be bacon? 172.191.189.245 23:48, 7 June 2006 (UTC)

title: Cookbook talk:Potato Soup


text:
Space Transport and Engineering Methods/Introduction

About This Set

 This is the second volume of a two-volume set about building a better life for ourselves, our community, and the world. Building is meant in both the literal sense of construction and production, and in the social sense of how people work together to reach our goals. The core ideas behind our approach can be summarized as follows:

 * Resources and energy are abundant on Earth and in space.
 * With enough knowledge and tools they can be used to build a better life.
 * With planning this can be sustainable and avoid unwanted side effects.
 * Cooperation makes it affordable and self-improvement makes it scalable.
 * Smart tools can do most of the work and make it easier.

  Volume I on Seed Factories and Self-Improving Systems covers the basics of these ideas, including their history, elements of designing such systems, and a design process. We then present several examples of projects and systems that use this approach on Earth. Each example is designed to grow internally by self-improvement, and externally by enabling copies of their starter sets. The examples are linked as earlier ones can grow into later ones, can make parts for them, or can make complete starter sets for later ones.

 This volume covers the very different conditions and locations of space beyond Earth. We first look at the science and engineering fundamentals that relate to space. Since you must get there before doing anything else, second are technologies for reaching space and moving once there. Third are specific engineering technologies that apply to space projects. Part 4 continues the series of projects and systems from Volume I to orbital and planetary locations, ending with those beyond the Solar System. Part 5 provides some design studies as examples and for practice while learning the subjects discussed. We finish with references and sources that don't fit elsewhere in the book.

 We cover past and current space projects and programs, but also many future methods, technologies, and projects which require research and development. Not all of these will prove useful, but we include all that we know of. When starting a project it helps to know what other people have done and thought of. This avoids repeating work and helps identify options. The online format is also intended to address some of the limitations of traditional printed textbooks:

 * Their high cost in recent years. Wikibooks are free and open-source.
 * Difficulty including or linking to other media types, such as audio, video, simulations, and software.
 * The relative difficulty of updating printed books in a fast moving field.
 * The very large amount of information in this field. These volumes are not limited by printing technology and we are building a supplementary reference library.
 * Learning involves more than just reading. So we include some projects which interested readers or teams can use as design practice, or even build.

About Space and Space Projects

 Our planet is located in space, as thus photo of the Earth from a distance shows. Space is not a different place to go to - we are already there. We think of it as somewhere else because most of us spend most of our lives in the most usable areas near the surface of a single planet among the billions in the Galaxy. This is where we evolved, and where conditions are reasonably habitable for us, so we think of it as normal.

 In reality, our comfortable planet is the exception. The vast majority of environments are hostile to life as we know it. We can use and live in such places with technology, just like clothes and fire allowed us to live in cold parts of the Earth, and boats allowed us to cross oceans. For space, we first learned how to build equipment that can work there. After that we started building artificial environments like capsules, spacesuits, and space stations. These let people live in space for varying amounts of time. So far the most people in space at one time is about 17 out of 8 billion total population. So living in space has only barely started.

 In the future we may start changing space environments to make them more livable. In principle we can also change ourselves to better live in space, but it would be hard to do that for all the other kinds of life that exist on Earth. Reproducing earth-like environments is simpler to start with.

 As of 2021 the Global Space Economy had reached US $386 billion/year, about 0.4% of global economic activity. This is expected to greatly increase in the future as we learn more about using space and expand into it. The energy and material resources of space are vastly larger than those on Earth, and using them can minimize side-effects to the Earth's environment. Both economics and protecting the planet make space systems engineering is a worthy field of study.

 The main challenges for space projects in the past were rockets that could reach space at all, and designing relatively small satellites (as a percentage of their weight) with finite lives that they could carry. These topics are adequately covered by existing textbooks such as Sutton's Rocket Propulsion Elements and Griffen and French's Space Vehicle Design.

 Starting with more recent projects, like the International Space Station (ISS), new design features have become more important. These include long-term habitation, evolution and growth, sustainability, and industrial capacity. Future projects will require new types of propulsion, life support, production, and assembly. Single projects can no longer be considered in isolation, either. For example, the ISS depends on multiple launch vehicles to deliver crew, supplies, and hardware, and on relay satellites to communicate with Earth. One reason for this volume is to address these recent and future changes that are not covered by past textbooks.

Links to Additional Material

 We cannot fit the entirety of knowledge about space systems and projects into a book-length introduction such as this one. So we will include extensive links and references to more detailed sources. The Seed Factory Project, of which this volume is a part, has built a reference library of some of the more useful publicly available articles and books to supplement this set. We cannot distribute copyrighted works from that collection without permission, but we can provide lists and where to find them for interested readers.

 Note that popular culture incorrectly calls Space Systems Engineering "Rocket Science". It is part of engineering rather than science and not exclusively about rockets. We hope that serious students understand the difference.

 Engineers use other tools besides books to do their work, such as simulation software and spreadsheets. Wikibooks does not support including software files, so links to where these items can be found are intended to be added over time.

 A 2023 Report we produced is a shorter introduction to our ideas and proposed projects. We are incorporating ideas from it into this set.

Detailed Book Organization

 This book is organized as a progression from science and engineering fundamentals (Part 1), to technology elements (Parts 2 and 3), to complete projects linked into a combined program (Part 4). Part 5 is intended to present example design studies that show details of the process. The volume ends with general references and sources not already included in the body of the book, and data appendixes.

 Each part is divided into numbered chapters, and chapters have sections and subsections for internal referencing. We will try to emphasize underlying principles and key design parameters, as those have more lasting value than, for example, the particulars of a current rocket.

 We include many methods and concepts which are not in current use. The reasons are first, when starting a new project, it is a good idea to at least briefly consider all the possible alternatives, before narrowing down to the most relevant ones. Second, this is a future-oriented book. While a concept may not be useful today, knowing what the state of the art is and what technology areas to watch helps to tell when it will become useful. Third, having all the ideas in front of you might spur a new combination or application that had not been thought of before. This has happened to me (Eder) more than once, so I can attest to its usefulness.

 Part 1: Science and Engineering Fundamentals

 All of engineering depends on underlying knowledge from mathematics and the sciences. So we start with some basic information the reader should be familiar with, and the more important principles, formulas, and methods which apply to space systems (Chapter 1.1). The largest part of this is Physics, but also some key ideas of the other sciences, including Astronomy, Planetary Science, and Chemistry.

 Bodies in space are always in motion relative to others, and far from each other compared to distances on Earth. So next are orbital mechanics (1.2), and what forces (1.3) and energy sources (1.4) are available to artificially move to chosen destinations.

 Following that we introduce general engineering methods, including the discipline of Systems Engineering (Chapter 1.5). The goal of systems engineering is to optimize complex systems over their life cycle. Larger space projects are complex enough that this method is very useful. Complexity also demands ways to track the details and keep a project as a whole a coherent. Note that smaller and simpler projects, like some of those in Volume I, don't need this level of design and analysis.

 We then introduce the tools that engineers use in their work (1.6), followed by the variety of specialty engineering disciplines such as structural and electrical design which are used in parallel with the overall system optimization (1.7). Most larger projects use specialists in different areas, because there is too much knowledge for any one person, and simply a lot of work needed.

 Early concept work can be accomplished by one or a few people. As larger projects develop, more people are brought in with the right skills to work on the details. This in turn demands efficient organization and coordination within a project team (Chapter 1.8). Economics addresses other resources needed in a project besides people and knowledge, including funding and financial analysis.

 The last two chapters of Part 1 summarize existing programs (1.9) and topical areas for future projects (1.10). Proposed future projects should be compared to existing ones to see if they give enough improvement to justify their creation. The range of future activities also helps identify goals, requirements, and growth paths.

 Part 2: Transport Technologies

 We noted that before you can do anything else in space, you first have to get there. So Part 2 discusses ways to reach and then move around in space. Past rockets could only carry 5% or less of their total weight as cargo to orbit, and less to farther destinations. Increasing the cargo fraction and reducing cargo weight became the primary focus of space projects. But those efforts made the cost very high. Although still important, we take a more balanced approach in this book. Improved transportation and using materials already in space will shift the mass balance towards the destination. So this book gives equal attention to transport and using local resources.

 Many more technologies have been proposed (about 75) than have actually been used so far (about 5), and one of them, Chemical Rockets, has been used by far the most. Chapters 2.1 through 2.10 list the many known and speculative technologies by category. After listing the available concepts, the last chapter (2.11) makes some comparisons, and discuss how to select the best candidates for a given project.

 Part of the reason chemical rockets have been used so much is "first mover advantage". They were the first type of space propulsion to get serious development. They have the longest history, most optimization of design, and most familiarity, so they continue to be used. That does not mean they are objectively the best solution for all time, and all circumstances. Use of other methods, such as electric propulsion, is becoming more common in recent years.

 As we noted above, when starting a new project, a survey of all possible technical choices is worth doing, before narrowing the list down to the best candidates. That way no good option is overlooked. That is one reason Parts 2 and 3 attempt to be comprehensive. Also, no single method is optimal for all locations and project needs. For example, it is now common to use a chemical rocket to reach an initial Earth orbit, and electric propulsion for orbit changes afterwards.

 Part 3: Engineering Technologies

 Part 3 considers the production and operation technologies used to reach space, and how to use its resources once you get there. Reaching space is a subset of manufacturing on Earth. Use of self-improving systems on that scale is covered under in Chapter 7.0 Industrial Production in Volume I. Production in space, and later use of the products, can use many of the same methods and technologies used on Earth, but adapted to local conditions. There are also some new methds unique to the space environments and resources. The mix of which to use will generally be different for space than for Earth, and differ by location in space.

 Chapter 3.1 lists overall design factors which affect multiple parts of a space project. Having accounted for transport in Part 2, we then explore the other subsystems that make up a complete system or project (3.2). A large program or project will often have multiple system elements with different purposes and functions.

 The remainder of Part 3 covers technologies adapted for or unique to space. This includes finding resources (3.3), extracting them (3.4), turning them into useful materials and parts (3.5), assembly and construction (3.6), verification and test (3.7), operation and maintenance (3.8), and finally recycling and disposal (3.9). As we use those terms, a "technology" includes the knowledge and tools needed, a particular "method" describes in general how a given task is done, and an engineering "design" then implements that method in a specific instance.

 The approach for most space projects so far was to do all the design and construction on Earth, and then launch pre-built and pre-supplied complete items like communication satellites or interplanetary probes. This was adequate for smaller projects. As larger ones are developed it becomes unreasonably difficult and expensive.

 The International Space Station is an example where it was too large to launch as one complete item, with supplies for its full operating life. Instead it was assembled from smaller parts that each fit within a single rocket launch. Supplies and new equipment are delivered periodically. This reduced the payload per launch to a manageable size, but all the parts and supplies are still being brought from Earth.

 As larger and more distant projects are considered, the transport requirements continue to go up, and becomes very expensive. This is mainly due to the deep gravity well of the Earth, which requires a lot of energy to climb out of. At some point it becomes more economical for a space project to extract supplies and energy, and eventually do production, locally. Our book gives a lot of attention to these tasks. Doing them in space is new, but there is a long history of engineering on Earth which can serve as a starting point.

 Part 4: Complex Programs

 Part 3 looks at individual systems or projects. Part 4 then considers complex programs that evolve over time or involve multiple systems. A key point to understand is no single system works best in isolation. For example, a vehicle without a fuel supply can only travel once, with it's original fuel load. A fuel extraction plant can do nothing without raw materials to work with. Combining these, vehicles can transport raw materials to the plant, and get fuel from the plant for later trips. Then the combined system can operate indefinitely as long as a surplus of fuel is produced from each trip. To design a complete program, you then need to look at all the component systems and how they interact.

 The parts of a program not only interact, but they can also evolve over time. We can use a highway program on Earth as an analogy. Individual roads started as footpaths, and were upgraded in steps. The upgrades depend on the types of vehicles that will use them, and the existing roads were used to deliver machinery and supplies to construct the upgrades. Individual road projects also connect to form a highway network whose parts must work together. So it will be with sensibly designed large space projects: one set of vehicles and facilities are used to help build the next level of improvements, with all the parts working together.

 Part 4 has an extensive example of a complex program that both interacts with itself and grows over time. This example serves several purposes. One is to demonstrate how such a program is analyzed and defined. Where different options are presented, we explain how to choose among them. Another purpose is to serve as a proposal for a real-life program that begins with improving life on Earth, then moves into space. In that context you have to go past pure design questions and consider economics and other external factors that apply to such programs.

 The final purpose is for learning by the "class project" or "lab experiment" method. Skills like working in a team are best learned by doing, and using new knowledge in a project helps fix it in memory. Taking an unfinished part of our example to the next stage of design can be used as a learning tool. Experience working on a realistic design can also be useful if someone intends to work in this field in the future.

 Our proposed program is likely not the best one imaginable, but it is intended as a starting point to develop further. As individuals and teams use these volumes for their own learning and self-improvement, we hope they will make suggestions and provide feedback so it will improve over time, both as a proposed program and teaching tool.

 Part 5: Design Studies

 In this part we include or link to the details of design studies for elements of the program described in Part 4, and other studies we have done. This allows the narrative in the earlier parts of the book to flow without interruption by a mass of detail, and also serves as examples of the types of studies and reports which engineers are frequently asked to work on. The full details showing the step by step assumptions and calculations are usually kept as part of a project's work history, and the results are distributed as reports and other document types for others to use.

 The first study is a concept-level design for human expansion beyond Earth. It starts by identifying goals and benefits, then criteria for deciding among multiple options. Program-level requirements are then developed to meet the desired goals, and a design approach to meet those requirements. The next part of the study is identifying functions and phases within the overall program. Since various space programs and private projects already exist, the last step is identifying what changes or additions are needed to them. The results of this study have been incorporated into the program described in Part 4.

 The first study was a broad one covering a complex future program. The second one is more specialized to identify difficult and extreme environments on Earth and in space. Knowing the environment conditions guides the design of equipment and projects that must operate in those environments. The third study is about the need for, justification, and design of an "Open-Source Space Program", by analogy with open-source software. Past government and commercial space projects have been "closed-source" for national security or business reasons. Open-source software development has been fairly successful, so it is worth at least considering using such methods in other areas.

 References and Sources

 This volume includes links to references and additional data in two main ways. References or sources that are specific to one method or idea are linked in the main body of the book. In-line links are boldface and capitalized. Additional references that cover multiple topics are included in this last section, along with appendices for data that does not fit in the main text. T

 The first appendix, for example, lists fictional transport methods which do not have any scientific or engineering basis. They are there for completeness, but as there are no practical prospects to use them, we put them in a separate section rather than the main body of the book. Additional appendices will include reference data that are particularly useful. Most reference data will be linked to as outside references.


text:
Talk:Space Transport and Engineering Methods

Origin of This Wikibook
This wikibook was originated as a port of the "Canonical List of Space Transportation and Engineering Methods" by Dani Eder (wiki account Danielravennest). The latest version I had prepared of that document (version 0.79, 26 July 2001) was on Geocities. A saved copy can be found at oocities.org

I worked for Boeing for 24 years on space related projects. Over the years I accumulated a lot of information on space propulsion and development. I started keeping a list of references organized by topic, which grew into the above document. As the internet developed, it was posted at various times, eventually ending up as a geocities web page.

An article entitled "60 Ways to Leave Your Planet" by W. Dan Leonard appeared in "Final Frontier" magazine about the list (May/June 1990, page 42).

I hope in this wikibook form it can develop further into a useful reference. Danielravennest (discuss • contribs) 05:59, 27 February 2012 (UTC)

Status

 * Initial Outline Progress

Based on age of the original Canonical List from which this book originated, other documents I plan to merge, and amount of text in the various sections, I estimated progress towards an "initial outline" to be:

 * text completion: 25% @ 4 March 2012 - illustrations, tables, and scanned media: 1%, references and notes: 4%
 * text completion: 37% @ 14 March 2012
 * text completion: 45% @ 24 March 2012
 * text completion: 60% @ 6 April 2012
 * text completion: 80% @ 23 April 2012
 * Text completion: 100% @ 16 May 2012.

Initial outline meant the structure of the book was complete, and many sections had some level of text completion, but there are still significant holes. From this point the goal was to add more illustrations and references, fill holes, and improve the text and presentation. Danielravennest (discuss • contribs) 02:31, 17 May 2012 (UTC)

 * First Draft Progress

First draft means all the book sections have substantial text, and supporting works (technical papers, design studies, spreadsheets) are partially done. Quantity is not a substitute for quality, but I have set a target of 500 equivalent pages of 500 words each as "textbook length", or 250,000 words x 6 bytes/word average. I have also arbitrarily set a goal of 1 link/reference per 200 words and 1 graphic (table, illustrations, and similar) per 1000 words. This just lets me keep track of progress as I work on my contributions. Based on those targets, the status was:

 * 16 May 2012: Text 40%, Graphics and References not yet counted
 * 05 Jul 2012: Text 52%, Graphics 8%, References 28%
 * 02 Sep 2012: Text 60%, Graphics 10%, References 47%
 * 08 Jan 2013: Text 93%, Graphics 8%, References 37% (graphics and references percentage regressed because they are relative to a larger text base)

Danielravennest (discuss • contribs) 18:04, 11 January 2013 (UTC)

Merge
I see no reason to repeat the description of every kind of rocket in 2 different places. I see 2 ways to avoid this unnecessary repetition:
 * (a) I suggest merging the entire book Rocket Propulsion into Space Transport and Engineering Methods, creating one huge book. Or,
 * (b) Pull all the "rocket propulsion stuff" out of the "Space Transport and Engineering Methods" book and put it in the "Rocket Propulsion" book, leaving 2 books: "Space Transport and Engineering Methods (except for rocket propulsion)" and "Rocket Propulsion".

I'm leaning towards (a), but you may be able to convince me to do (b). --DavidCary (talk) 02:48, 15 September 2009 (UTC)

Merge Progress

Merge complete. How do we review the merge and then delete the other book?

 * I have posted a partial answer on David's talk. A simple review is made by the acting administrator (but only on the use of the content not a real quality assessment) as you tag the pages with the now merged tag you provide the destination page indication that is probably missing on your edit comments.
 * I've looked at the last ones and have only a merge indication (not the source), not a major issue but makes a second person to fallow and do a review extremely complex if only working on them. --Panic (discuss • contribs) 23:27, 17 April 2012 (UTC)

Regarding content
Shouldn't content that is not about space transport and it's engineering methods be moved to other works. I noticed that there are some sections covering colonization and prolonged stays, even terraforming considerations that would be best merged into Colonizing Outer Space. Any views on this (not urgent) but it seems that the material may be missed under the current title and/or duplicated on the other work. --Panic (discuss • contribs) 15:48, 22 April 2012 (UTC)

 * The book title means 'Space Transport Methods' + 'Space Engineering Methods' as distinct topics with one part of the book dedicated to each. Colloquially the first is how you get there, and the second is what you do once you are there.  As the Introduction makes clear, you cannot consider them in isolation.  A vehicle is no use without a refueling station, for example, or a space colony is of no use if you don't have a way to get people there.  The Combined Systems section then gives an extended example of how you put the pieces together, including calculations, to make a logical sequence.  I know the book has holes, like illustrations are pretty much non-existent, but I hope that clarifies the direction I was heading in. Danielravennest (discuss • contribs) 00:15, 23 April 2012 (UTC)

 * Then renaming of this work to something like Exploring/Understanding/A look into/Past and Future of/etc Space Engineering (something that doesn't define or limit the scope) and merging Colonizing Outer Space may seem in order no ?
 * In regards to Transport and Colonization I do not see them as strongly connected but do in regards to Engineering. When we discuss future colonization efforts (specifically) we need to cover not only engineering matters but social, political, economical and even architectural and cultural aspects.
 * Transportation is only relevant until an optimal solution to the different requirements is found after that technologies will compete more on economical costs and trip time then in specifically Engineering concerns. --Panic (discuss • contribs) 00:44, 23 April 2012 (UTC)

 * I was referring specifically the content in chapter 4 section 9,10,11 and 12. Except a brief requirement to cover future transport methodologies (that is already present in the other book) all content has little to do with Engineering (being Engineering a precises application of science for the creation and application of reproducible methodologies,processes and systems). --Panic (discuss • contribs) 01:00, 23 April 2012 (UTC)

 * I agree that colonization is a much wider topic. Looking historically, colonizing the New World (Americas) involved all those aspects you mentioned. What kind of ships they used and what tools were brought along is only a small part of the story, and I didn't intend to cover all aspects of colonization. MIT calls the field I intended to cover "Space Systems Engineering", so I would be OK with that for a title. I note, however, that engineers design things for other people, and analyzing what it is they want (requirements analysis) is part of the process which cannot be ignored. So for example if you set the problem as "design a transportation system to support a Mars Colony", you then have to ask how many people, when do they get there, and how self-sufficient they are. That last item affects how much you need to transport. So to find the optimum solution you have to consider the Mars greenhouses as well as what kind of engine is on your rocket. That sort of "looking at the whole problem" is what Systems Engineers do, and what I did as a systems engineer at Boeing's space division.  For now, I just want to finish writing the content.  What title to put on it and how it's organized can come later.

 * I'm not pressing the issue since I was mainly doing small maintenance on the Colonizing Outer Space even if I have an appetency for the subject. The points I was calling attention is that I felt there was a minor collision between the works on the later chapters and that those did not really seem well fitted for the subject matter covered in the rest of the book.
 * I take your point about mission designs but reading the work so far one is given the idea that mission designs should tendentiously evolve to be more generic and avoid being target specific (as much as they can) this not only reduces costs ans eases planing and even avoids errors in the supply chain. We can revisit the subject later and look in more detail if colonization issues can be reduced here (linking to the other work that is specially focused in that) the same can also be done on the other work on the section that are best covered here (they should if separated complement each-other).
 * I do believe that a rename would improve readers placing the book into its scope, and agree that the subject of rename is also not pressing at the moment and could be done later on, but we seem to agree that it would be an improvement.
 * I also make a minor personal comment. I disagree with the notion that "engineers design things for other people". Engineers tend mostly to design things for other engineers :) Only the most basic of system and process engineering can be comprehended by one that is not initiated in the not so mysterious processes of science, physics, mathematics and logic. We live in an age that is marked by reaching the pinnacle of demographics, yet these marvelous knowledges are by most seen as arcane and unnecessary... --Panic (discuss • contribs) 23:29, 2 May 2012 (UTC)

Cover Picture
Rather than a photo of the Space Station, which is a past project, I think a future project representative of the contents of the book would be better. Something like a Lunar surface base illustration, with mining rovers, a structure being assembled, and a rocket vehicle. For now the ISS photo is OK as a place holder. Danielravennest (discuss • contribs) 14:20, 13 May 2012 (UTC)

Some ideas
I particular would like this project more focused, but there are some aspects that could benefit what is covered information about how to deal with engine vibration and heat and radiation shielding in all areas, would be interesting to have some coverage. --Panic (discuss • contribs) 23:23, 31 August 2012 (UTC)


text:
Space Transport and Engineering Methods/Methodologies

Engineering applies scientific principles and other forms of knowledge to design, build, and operate systems which perform an intended function. It is a broad discipline, whose parts we will discuss later in Section 1.7 – Engineering Specialties. In a simple project, such as designing a bookcase for home use, a formal engineering process is not needed. One person can calculate the shelf loads and other parameters by themselves, with the help of a calculator and some reference data. Large and complicated projects, however, need the knowledge of multiple specialists, must satisfy multiple desired conditions and functions, and involve large amounts of time and money. A need then exists to coordinate the work, and ensure the final product meets the intended goal, in the most efficient way. Systems Engineering methods have been developed for this coordination task. They have become their own specialty field and are used in addition to the other engineering specialties. Systems Engineering can be used for any type of complex project. However, space systems are usually complicated enough to benefit from it, and systems thinking and methodologies are often used in this field.

What is a System?

Given an identified need or desire, how does one select the best design to satisfy it out of the infinite number of possible solutions? For a complex project, the concept of a System has proven useful. A System is defined as a functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements. They are distinguished from the rest of the Universe by a System Boundary (Figure 1.5-1). A system is not a physical entity, but rather a mental construct, created because of it's usefulness, by drawing a line or surface around a collection of elements. The elements have internal relationships to each other and form a comprehensible whole. The rest of the Universe outside the system is referred to as the System Environment, or simply the environment. Flows of many types enter and leave the system as Inputs from and Outputs to the environment by crossing the system boundary. The scope of a given engineering task is then defined by the system boundary, what crosses the boundary, and what is inside. Systems may contain smaller systems within them, which are called Subsystems. These may be nested to any level, but flows into and out of a subsystem must appear in the parent system, or at the top level in the environment. This rule may be called Conservation of Flows – that flows do not appear from or vanish into nothing. Following that rule ensures that all the required inputs and outputs are accounted for.

Systems Engineering Method
A single person may have the time and knowledge to do a preliminary concept or design. A complete space project is usually too complex or would take too long for one person to do. So the Systems Engineering method can be used to help carry out such projects. Aerospace projects, including space systems, are particularly suitable due to their complexity, and were among the main ones for which the method was developed. The method focuses on how projects should be designed and managed over their entire Life Cycle, that being from initial concept to final disposal. Since it applies to the whole project, it is interdisciplinary, connecting tasks performed by Systems Engineering specialists to those of other engineering branches. Key parts of the process include:

 * Breaking down a complicated project in such a way that the smallest pieces are simple enough for humans to design.
 * Modeling the system so it can be analyzed and optimized, and comparing the actual physical system to the models.
 * Control and track the information and design of the pieces and their relationships so the total system will do what you wanted.

Figure 1.5-2 illustrates in general the steps within the Systems Engineering process. The trend is from top to bottom, but we do not show arrows connecting the steps because it is not a strict linear flow. As results are obtained in any task, they can feed back to earlier steps in an iterative fashion, until a stable design solution is reached. So these tasks can happen in parallel, and applied across the different stages of the life cycle. The tasks can also be applied at different levels of detail. They are started at a general level. Once a stable configuration is reached at one level, it then is re-applied at lower levels until detailed design can be done on individual elements. At all levels, there is communication with design specialties, and with outside entities such as the customer, suppliers, and other scientific and engineering organizations. The steps are described in more detail in sections 3 and 4 below and on page 2. It should be noted that an organization capable of designing and building complex space systems is itself a complex system. While it is not often done, Systems Engineering methods can be applied to the organization itself to design and optimize how it functions, or to any complex system of any type, not just space hardware.

The systems engineering process is bounded by natural and human-made constraints. Many of the human constraints are not directly related to design in the way physical properties of materials are. These indirect constraints include economics, laws, and safety of life and property. The process is then also outward-looking, beyond the design itself. Other engineering specialties are more focused on the internal details of the design.

Large Scale Systems
It is not required that a single organization do all the Systems Engineering tasks. Some very large systems, that have been deliberately engineered, such as the US Interstate highway system, the Internet, and the US program to land humans on the Moon, involved many entities working together. A national system of government, human civilization, or the Earth's biosphere can be considered as very large systems in terms of having inputs and outputs, a system boundary, and an external environment. There is a growing understanding that such large entities are systems composed of many smaller systems, whether designed or not. Analyzing such large entities as systems can help with understanding how they function and determining if corrective action is needed. Although some attempts at designing governments have been made, they have yet to be done based on scientific and engineering principles. Climate Engineering, which is the concept of deliberately affecting the Earth's climate, is an example of biosphere level engineering projects. Doing them deliberately, as opposed to the inadvertent side effect of civilization, is still in the conceptual stage. More work has been done in the field of Economics in analyzing economic systems, and sometimes attempting to design or influence them.

Reference Sources
As a well-developed engineering specialty, there are a number of reference books, standards, and special methods and software used by systems engineers. They are used to understand and manage the interactions, and communicate the current state, of a complex project. The remainder of Part 1 of this book summarizes parts of the systems engineering method. This includes the elements of a system, engineering tools, involvement of other design specialties, and economics. A given program also has to be understood in the context of other existing and future programs. All of these tools and knowledge must be integrated properly for a new project.

For additional detail on Systems Engineering beyond what is in this book, see:

 * BKCASE Project, Systems Engineering Body of Knowledge wiki, v1.8 – 27 Mar 2017.
 * DAU Press, Systems Engineering Fundamentals, 2001.
 * NASA, Systems Engineering Handbook, 2007.
 * NASA, Systems Engineering Class Materials – Website developed since approx. 2008.

The System Life Cycle

Complex systems evolve through a Life Cycle much the way living things do, from conception to disposal. The life cycle is divided into a number of stages where different tasks are performed (Figure 1.5-3). The design stages (the first three boxes in the figure) can be organized in different ways depending on the nature of the system. These include linear, parallel, spiral, or closed loop sequences, or some mixture of these. The illustration shows a typical linear sequence. A spiral process repeats stages in increasing detail, while a closed loop repeats at the same level of detail. Beyond the design stages, the process is more typically linear from production, through test, installation, operation, and retirement.

Life cycle stages are used for two important reasons. First, the design process should consider all the later stages, so that the best total solution is found, rather than optimizing for just one part of a system's life. Second, breaking down a system by time is another way to simplify the design work, along with breaking it down by subsystems and components. The stages are further broken down into internal tasks which have inputs and outputs that connect them, and have decision points for when it is time to proceed to the next stage.

A life cycle is a time oriented view of an entire system. Other views of the same system include functional diagrams, which show what tasks it performs and their inputs and outputs, and a work breakdown, which tabulates the elements and sub-elements which make up the system. Which view of the system is used depends on the design task at hand, though all the views need to be kept current or the design process can become disjointed.

Life Cycle Example
The names, and the task contents, of a given project's stages can vary according to the needs of the project. However a somewhat standard linear flow is often used in aerospace engineering, including space-related projects. The stages and typical major tasks include:

 *  Conceptual Design

 * Identifying the need – what is it you want the system to do? This is embodied in goals and requirements.
 * Establish selection criteria – how do you decide one design is better than another?
 * Establish a system concept – this includes the main functions, operation, and maintenance of the system.
 * Feasibility analysis – can the need be met at acceptable cost, schedule, and other parameters.

 *  Preliminary Design

 * Functional analysis – identify and break down the complex system into smaller functions and their relationships, including alternate arrangements
 * Design Allocation – subdivide and assign requirements to lower tier functions
 * Formulate alternatives – develop alternate solutions – what are the range of possible options?
 * System Modeling – develop mathematical models of the system so variations can be assessed.
 * Optimization and selection – making each option as good as it can be, then compare options and choose the best.
 * Synthesis and definition – combining the selected options into a total design, and recording the configuration and requirements details

 *  Detail Design

 * Design – Once broken down to a low enough level, individual elements are assigned to engineering specialties or design teams to complete. Design includes physical hardware components and facilities, as well as software, operating procedures, training, and other non-physical elements.
 * Integration – Design elements are combined into larger functional units that work together, up to the system as a whole.
 * Engineering Models and Prototypes – Physical partial models and complete prototypes built to validate the design.

 *  Fabrication and Assembly

 * Production of components – For physical items, the step where you make the parts.
 * Assembly – Putting parts together into complete elements.

 *  Test and Verification

 * Element and System Test – At each assembly level, testing that the assembly functions, then moving up to larger assemblies to the final product.
 * Verification – Proving the system meets the stated design requirements, by a combination of test, demonstration, inspection, and analyses.

 *  Installation and Deployment

 * After production, the system elements may need delivery, installation, and activation at the location they will be used.

 *  Operation and Maintenance

 * Operation – Using the system for the purpose it was designed, in the intended environment.
 * Support – which includes operator training, performance monitoring, and logistic support.
 * Maintenance – includes planned maintenance and unplanned repair, and in-place upgrades.

 *  Decommissioning

 * When the system has reached the end of its useful life, the removal, recycling, and disposal of system elements, and return of former sites to their original conditions.

Life Cycle Engineering
As a process that applies across the whole life cycle, Systems Engineering is not just used in the initial design phase. Part of good design practice is to know when to stop designing. A design can always be improved with more work, but at some point additional work does not provide enough added improvement to justify it. At that point the design should stop, and the system progresses to the next stage, which is usually fabrication and assembly. With time, the original design assumptions for a project, such as the available technology level, or launch to orbit traffic levels, will change. The systems engineering process can then be re-applied to see if a design change, upgrade, or even complete replacement of the system is warranted. Even if the system was optimally designed when first created, future events may require changes. If the system was properly modeled and documented, then monitoring of these external changes will reveal when it is time to restart the engineering.

Requirements Analysis
Developing a new system starts with a desire or need which cannot be satisfied by existing systems. The needs and desires are expressed by a Customer, For systems engineering purposes, the direct customer is the person or entity who is paying for a project or can direct the engineering staff. For example, in the Boeing Company, that is the engineering managers and general managers of the company. The ultimate customers, which are airline passengers, cannot express their desires directly. So the company management serves as a proxy to express their desires as an input to the engineering process. Other methods, such as surveys, can be used to determine the desires of the ultimate customers.

The initial expression may be in the form of general verbal goals, system properties, levels of technical performance, and similar statements. The customer also will have some value preferences which describe what a better design is from their point of view. These can be things like "minimum cost", "minimum waste output", and "maximum efficiency".

The first major systems engineering step, Requirements Analysis, is the process of converting these general customer desires and preferences to specific measurable features which can be used for design and evaluation. Two main parts of this process are Requirements Definition and Measures of Effectiveness.

Requirements Definition
The highest level general desires are first converted to specific measurable features and values called System Requirements. These are later broken down into more detailed lower level requirements, which are assigned to logical elements of a system called Functions to perform. The assignment ensures that somewhere in the system all the top level goals are met. At the most detailed level a subset of the lower level requirements are assigned to a single function box. This now becomes the detailed design conditions for that function. Assuming the analysis has been carried to a low enough level, the detailed design of the element that performs the function can then be done with a reasonable effort.

The first step in requirements definition is documenting the original desire or need of the customer in as much detail as they can provide. We will use as an example the Apollo program to land humans on the Moon. That was expressed by President Kennedy as a well known goal with a deadline. That very general statement was not sufficient to design the hardware. The key task is to put all the requirements in forms that can be measured so that you can tell when you meet them. Experience shows if a desirable feature or parameter is not expressed and measured, it will not happen as desired. An example of this failure is the Space Shuttle Program. The original goal was to fly 60 times a year. Given a fleet of 4 Orbiters, each one had to fly 15 times a year, or one launch per 24 days. Subtracting 7 days on orbit and one day before and after flight for launch preparations and post-landing recovery, that leaves 15 days to complete ground processing. The stated goal was thus 160 hours for ground processing, composed of 2 shifts (16 hours) x 10 work days over two weeks, thus 14 days. This goal was expressed, but it may not have been included in the system requirements, and it definitely was not allocated to lower tier hardware and tracked at the lower levels like hardware weight was.

Only after the Shuttle was already flying was it noted that ground processing was taking too long, and efforts started to reduce it. At that point it was too late to make any fundamental changes in the design, and so ground processing never got below about 800 hours, about 5 times the original goal. This was a major contributor to the Shuttle never reaching its intended flight rate. In order to have reached their goal of 160 hours, processing time would have had to be allocated to sub-systems, such as landing gear or maneuvering thrusters, and then each subsystem designed to meet it's assigned time. Conversely to processing time, weight has always been a tracked parameter in aerospace systems, since airplanes cannot function if they are too heavy. The Space Shuttle had very detailed weight targets and a tracking system by component, with monthly reports. It more or less reached its design payload, which is the 1.5% of available launch weight remaining after the vehicle hardware and fuel are accounted for.

This example emphasizes why desired features must not only be stated quantitatively, but passed down for engineers to meet in detailed design, and tracked so you can tell if you are going to meet them. Measurable parameters can be a simple yes or no, for example "Does this airplane design meet FAA regulations?", or it can be a numerical value, range of values, table, formula, or graph indicating the range of acceptable values for that system characteristic.

Measures of Effectiveness
Desired features are often in opposition. For example, higher performance and reliability often come at the expense of higher cost. There are also alternate designs which have different amounts of each feature. Establishing Measures of Effectiveness is the quantitative method to account for these disparate features at the level of the whole system. Like requirements, they are derived from customer desires. In this case it is what features would be "better" when comparing one design over another. Since different features typically have different units of measurement, they need to be converted to a common measuring scale. This is done by formulas that convert each different value, such as cost or performance, to a score. These scores are given relative weights based on their importance to the customer. The weighted measures can then be used in a single mathematical model or formula to determine "better" as a total score, when the component values vary across different designs.

The value scale is often in a range such as 0 to 100%, or 1 to 10, but this is arbitrary. What is more important is a definite conversion from a measurable feature to a scoring value, and the relative weights and method of combining them to a total score. As an example, a value of 0% might be assigned to a payload of 15 tons, and 100% to a payload of 45 tons, with a linear scale in between, and payload given an importance of 30% in the total score. The total scoring system becomes a mathematical model of the customer's desires for the system. Getting a customer to define "better" in such detailed numerical form is often difficult, because it removes their freedom to choose what they personally prefer in a design in spite of the engineering solution. It is necessary, though, if you really want an optimal answer. At the least this process makes it obvious when the customer is over-riding the engineering process.

It should always be kept in mind that a particular design solution may not be "good enough" in terms of it's measures when compared to existing systems. This can be found by including the existing system as one of the alternative designs being scored. In that case the proper answer is to stop development of the new system and stay with the existing ones. Often the cause is not enough performance improvement relative to cost, but other measures can result in a decision to stop.

Requirements Types
The following subheadings list major types of system requirements. Not all would be relevant to a given project, and others besides these might be important to the customer, so it is presented as a starting point for consideration. Each type can include more specific requirement values. The types listed here are linked and somewhat overlapping. For example high reliability and high safety generally go together. Requirements set limits on a design, and overlaps between requirements in effect overlap the range of limits they impose. This is acceptable as long as the designer understands the range of overlaps and interactions among the requirements. A particular design parameter will be governed by the strictest requirement when there is such overlap. An example from civil engineering is that earthquake, wind, and snow loads are all requirements to meet in a building design, and they overlap in that all of them affect the required strength of structural elements.

When broken down to lower levels of the system design, the requirement types and values will become more specific and detailed. Care is needed to maintain logical and numerical consistency across system levels. Requirements, or parts thereof, should not be inserted or dropped at lower levels. Traceability is the ability to follow the chain of requirements across the system levels, and is maintained by documenting how they are connected. This is necessary so you can prove satisfying the lowest level details actually meets the top level system goals. Historically the first two requirement types, performance and cost, were the primary ones considered. As systems have grown more complex and their outside interactions and side effects become better understood, the number of desirable features, and thus the number of requirements, have increased. This trend is expected to continue in the future.

Aside from the biblical Ten Commandments, requirements are rarely set in stone. Not all of them will be identified at the start of a project. As a result of interaction with the customer and feedback from the design process, they can end up modified. For example, a launch capacity of 10 launches at 100 tons each might be specified for a rocket, and later analysis show that 20 launches at 50 tons each yields lower total cost. The requirements would then be modified to reflect that. At any given time, however, the current set of requirements guides the engineering work. Over time, requirements become more firmly fixed, generally from the higher to more detailed levels in sequence. Changing a requirement forces rework of previous designs. So the cost of changing a requirement grows later in the process, and this tends to exceed any benefit from the change.

 Performance

Performance requirements are measures of the primary intended function of a system. Every system must have at least one performance measure for what it does, and often there are a number of them. As an example, the design capacity for space transport systems is often expressed as a Mission Model. The mission model quantifies the system performance in terms of multiple parameters like dates, flight rate, payload dimensions and mass, mission duration, destination orbit, type of cargo, and maximum g-level. For a space habitat, performance might be measured in number of crew supported, levels of atmosphere, food supplies, and gravity, and total living volume. An industrial system might have requirements for Throughput, in tons per day of materials processed, and Efficiency in terms of (theoretical energy required)/(actual energy used). The particular performance measures which matter will vary by system.

An example mission model for the Apollo program might have started out as follows, with more detail added as the project progresses. Even in this early version, it lists a number of different performance measures that the design needs to meet:

Cargo characteristics:

 * Number of crew to the lunar surface: 2/mission
 * Maximum Stay time: 4 days/mission
 * Additional science equipment: 250 kg/flight
 * Lunar samples returned: 100 kg/flight

Mission Schedule:

 * First Flight: as early as possible but before Jan 1, 1970
 * Flight quantity: 10 to lunar surface (this was the original plan)
 * Flight rate: 4 flights/year

Performance requirements only address what a system does when it is operating as intended. It does not address what happens outside that context, such as

 * In between active operation, such as the 80 days between Lunar missions in the mission model above.
 * When the system fails, as did the Apollo 13 mission,
 * Before and after the 5 years of manned missions.
 * Interactions external to the program, such the supply of technical personnel for the project, environmental impact of the launches, or return of Lunar germs to Earth. The last turned out to be a needless worry, but the quarantine system for returning astronauts and moon rocks is not something covered in performance measures.

So performance alone does not encompass the entire system over the entire life cycle, and other requirement types are needed.

 Cost

Cost represents the net resource inputs to a project from outside the system. Space projects don't use Dollars or Euro directly, but rather use them to pay for labor, materials, and services they do use. So cost is a measure of flows across the system boundary, rather than an internal property of the system. Every system will consume some resources during its life, but funding sources are not unlimited. So cost limits are almost always considered a requirement, whether implicitly or explicitly. Total cost over the entire life of the project is called Life Cycle Cost. This can be further broken down into development, production, and operations costs, and then accounted in much greater detail across the system elements. In addition to total cost, limits can be placed on spending rates. This is most explicit in government agency budgets, but even private projects have limits on spending per year. Some systems generate revenue to offset costs. When revenues exceed cost, the system as a whole generates a profit in financial terms. Revenue may be delayed until after the design and construction phases and the system begins to operate. The peak net cost accumulated until revenues exceed expenses is described as Capital or Development Costs. Customers generally want high performance and low cost, so the ratio of performance/cost is often a key measure for a project.

 Compliance

Performance and cost requirements are set by the project's customer with the help the engineering team. Compliance Requirements are set by external human rules such as laws, regulations, codes, and standards. Human rules often set minimum requirements in areas like safety. This does not prevent a system from adopting stricter levels. Human rules are usually designed to prevent undesirable effects. For example, speed limits on driving are intended to reduce the frequency and severity of accidents. Compliance requirements exist whether or not they are explicitly incorporated into the engineering process. It is better to incorporate them explicitly to avoid later problems. Other requirements are set by nature, such as the minimum altitude for a stable Earth orbit. These do not fall under compliance, but are accounted for elsewhere. In the case of altitude, this might be a performance requirement that a rocket deliver the payload to a 250 km high orbit.

 Technical Risk

Especially in the early stages of design, the engineering process may reveal gaps in knowledge, performance uncertainties, resources which are not available, or other issues which prevent selection, optimization, or synthesis of a design. These issues can prevent progress to the next stage of the project, or cause a final design which does not meet desired goals. Measures of these unknowns are given the general name Technical Risks. For example, a new technology which has not been demonstrated yet, i.e. a fusion rocket, would be rated as high risk, while a chemical rocket, which has decades of operating history, would be comparatively low risk. A mass budget considerably below past experience or with insufficient margin during preliminary design would be high risk. New research, modeling, or prototyping can be done to reduce the risks, or the system modified to avoid them. Before these risk reduction efforts the risks will still exist, and it is necessary to account for them. Otherwise you accept the alternate risk of the system not performing as desired or even at all.

Not every risk will be known at the start of a project, but sound engineering practice is to identify them as early as possible, and to allow for modifying development plans when they appear. Depending on how much new technology is included in a project, sufficient performance, time, and cost margins should be included for unexpected problems caused by technical risks. Technical risk is gradually retired during the design and production of a system. Once a system is operating, a small uncertainty remains for things like operating life or failure rates. These are not eliminated until the end of program operations. Even after disposal of a system, some environmental risk may remain. A prime example is nuclear waste, which is a hazard long after the reactor that created it has been demolished.

 Safety

Safety is the state of being protected against adverse consequences to living things, or damage and destruction of inanimate objects. It is an inverse measure of other risks than those under the previous heading. So a higher safety level is measured by lower risks. Under the principle of "protecting the innocents", hazards to a crew that volunteers to accept a risk can be higher than those allowed to the public at large. A safe system, such as a nuclear power plant or passenger airplane, may have less than one expected accident during the system life. So safety often involves assessing low probability events. Requirements to maintain control of a system despite failures, inherent fail-safe design, design margins, backup systems, and redundancy can improve safety when properly implemented.

 Reliability

Reliability is the probability the system will perform its intended function for a specified time period. The inverse is probability of failure. It is related to Resilience, which is the ability to function in the face of internal damage or external failures. It is also related to Robustness, which is the ability to function in the face of external or internal variables, such as line voltage or temperature. A closely related measure is Availability, which is the probability a system can start operating at a random requested time, or the percentage of a total time interval it can be operated. A high reliability system may require multiple units in place, so that at least the minimum required number are available at a given time. An example is passenger airplanes, which require multiple engines for high reliability, in case one stops working.

 Durability

Durability is how long a system can perform its intended function. It is typically measured in terms of service life. Service life of components, and of the system as a whole, is related to their maintenance. If not enough maintenance is performed, the life is reduced. Once the life of the item has been reached, it will need repair or replacement. Service life can be measured in terms of number of uses, operating hours, or calendar time. Durability is related to the economics concept of a Durable Good, one that yields utility over time rather than being consumed in one use. A passenger airplane has high durability, because it can operate for decades and tens of thousands of flights. The opposite of durability is consumption. The fuel used in the airplane is consumed (used only once), and is therefore not durable.

 Quality

Quality is a measure of how well a system meets expectations. One aspect of quality is a measure of the lack of variability or defects in the design and manufacturing stages of the life cycle. Variability and defects increase the chance that performance will fall outside required levels. Another way to put it is conformance to initial specifications. Wear or defects caused during normal operation are not a quality problem unless they are unexpectedly large. Normal wear would fall under maintenance requirements. Another quality factor is parameters like signal-to-noise ratio and error rates in electronic devices. Noise and quantum effects are natural variations which cannot be eliminated, but a large margin above those variations in effect reduces variability and increases quality.

 Sustainability

Sustainability is the capacity of a system to endure. For example, does a system consume a scarce resource or generate a waste output that limits it's long term use? If so, it is not sustainable over the long term, although it may last a desired system life. A current example is hydrocarbon fueled rockets. If obtained from fossil sources, they are both limited in supply, and cause unwanted change to the atmosphere. If they are produced as a biofuel, they can be sustainable.

 Community

These are requirements to have a positive, or at least minimally negative, impact on the surrounding human community. This might mean employing local staff, or avoiding traffic problems during a shift change, or noise impact from rocket launches. Positive educational impact is another community effect.

 Environment

Like community, these requirements relate to impact on the surroundings, but in this case the non-human portion. For space projects a key environmental requirement is to avoid contamination, either biological, chemical, or from radiation, both forward and backward from the ends of the mission.

 Manufacturing

This type of requirement covers items such as how many sources are there for a given manufacturing method, or how exacting the tolerances are. In sum they measure how easy or hard the system is to produce.

 Testing

These requirements deal with the types and quantity of tests required for a system. Development tests occur during the design stage, qualification tests occur during approval, and periodic inspection and testing may be needed during the operations stage.

 Maintenance

These requirements include parameters like hours and costs to maintain the system in an operating state, probability of system failure, and levels of spares required. A system can fail without safety risk. For example, your car may not start, which is different than the brakes failing to operate. The more often that items fail to operate, the more spares are needed in stock, and the more time and money to repair or replace items. So the various maintenance requirements are linked. Maintenance requirements can be divided into preventive, which is before something stops working, and corrective, which is after.

 Flexibility/Adaptability

This is the ability of the system to adapt to new tasks or functions, or different performance levels for the original tasks, than first designed for. Similar requirements come under names like Extension, which is adding new tasks or functions while keeping the original ones, or Agility, which is concerned with how fast the system can adapt. Reconfiguration is the ability to change the arrangement of a system to perform a different function. An example is the Curiosity rover, which had one physical shape and software load to cover travel to and landing on Mars, and a different arrangement of wheels, camera mast, and software for surface operations. The change of state was accomplished by a combination of mechanical design, planned sequence, and new software upload.

 Scalability

This is the ability of the system to change in size either by scaling the size of a unit, or by installing more units. There is always a limit to scaling imposed by some physical constraint. If the system can be scaled to meet the full demand for it without reaching scaling limits, it can be said to be scalable. Modularity is a related parameter, concerned with how separate the elements of the system are, and how easy it is to replace them with other elements of the same or different types. Instances of modularity can be horizontal – at the same level of a system, or vertical, as in the layers of the Internet Protocol stack.

 Evolution

This requirement type considers how well the system can change over time to a different type of system. It is related to flexibility, which is more about changes while staying the same kind of system. Redesign is concerned with the difficulty and cost of making changes.

 Usability

Usability requirements deal with the interface between humans and system elements. When a system can be used without great amounts of planning, preparation, physical strain, or training it is said to have high usability.

 Interoperation

This is a measure of how the system fits with other systems. For example, a new airplane with doors that did not fit existing gates, or a computer network that exclusively uses a new protocol that nobody else uses would fail in this parameter. Compatibility is more concerned with the direct interfaces between systems, such as the output of a computer video card matching the input to a monitor. These features are more prominent in the information technology fields because of the sheer number and variety of hardware and software elements which must work together (with varying degrees of success).

 Openness

This is the degree to which a system is composed of proprietary or secret elements compared to open, public, or standard elements.