Systems Engineering

Systems Engineering is a poorly-named field -- it's not so much an engineering discipline as a structured process for producing a design. Just as we can design a homestead , we can apply the Systems Engineering process to develop lasting documents.

The experiment I propose is this: can we apply the elements of the Systems Engineering process to create a constitution that ensures a sustainable and open community?

We have just about enough in the Objectives & Requirements Document for our Peak Oil Homestead Project to proceed with designing some suitable homestead concepts. Please keep in mind that you would likely want a few more requirements before proceeding with a design, but in the interest of time (and to keep everyone from losing interest) we’ll proceed with what we have.

This is a good time to note that one of the reasons it has taken so long to develop the methodology we’re using for the Homestead Project is that I’m working to adapt techniques to our small homestead more commonly used for large-scale industrial projects like the Space Shuttle. The underlying drivers are the same, but much of the available material has a much grander focus.

Now that we have plowed the road for applying Systems Engineering to designing for Peak Oil, further projects will flow much more smoothly. In the future we will design entire communities, constitutions, specific functional buildings (e.g. community medical facilities), and much more within a much shorter time span. So, hopefully you all have not lost patience with this process yet and are interested to see how all this designing plays out!

We’ll round things out with the following energy and water system requirements:

While not necessarily conclusive, this list of requirements should round out the bulk of overall top-level for the Peak Oil Homestead Project. From here we can move on to designing specific elements of the homestead and begin the process of developing trade studies. We’ll get there yet!

I updated the project page to include the relevant blog posts for each update. This should make the entire project a bit easier to follow and give people an easier time of tracing its development.

As always, feel free to post any questions about the project in general in the Community Design Forum.

Non-functional requirements make up the bulk of any Objectives and Requirements Document such as in the Peak Oil Homestead Example. They specify the qualities of the system that will provide the functions we desire. Below are some further non-functional requirements for the Homestead.

We have perhaps a dozen requirements scattered through the discussions in this blog that we have not yet incorporated into the Peak Oil Homestead Project. With the benefit of detailed requirements structure, it’s now an almost enjoyable task to plug them into the project.

In Global Warming meets Peak Oil Design, I introduced several potential requirements. Before I show you where to stash ‘em, I want to make some improvements.

The Peak Oil Homestead Requirements are now organized according to the structure discussed last week. The major subsystems of the homestead are given separate sections within the main Objectives and Requirements Document (ORD). Once the main requirements are fully developed and design solutions are chosen, further ORD’s will describe components of the major subsystems (e.g. cistern requirements).

This looks like a good time to introduce a more robust requirements management method for the Peak Oil Homestead Project. The original Objectives & Requirements Document attempted to align every requirement with specific objectives. This helped reinforce the idea that no requirement can be created in a vacuum – it must be backed up by goals and objectives.

Now that you understand the basics behind Systems Engineering, however, we need to select a more versatile organizational scheme to move the project forward. You may have noticed that as the project developed some requirements were left in the cold with no particular objective to call home. These included things like our maintainability and reliability requirements.

Lately I’ve been focusing a lot on sustainable Peak Oil solutions, but we need to make sure we don’t lose site of the design process. In the spirit of keeping organized (which is about 85% of Systems Engineering), I’d like to direct your attention again to our development of the Homestead Problem. The Objectives and Requirements Document (ORD) for the Homestead Problem is linked at the top of the right sidebar.

We’ve slowly developed a number of requirements over the past few months, and now you can see where they fit within the hierarchy.

There are some key ideas in requirements management:

Once you have developed your high-level requirements you can start looking at various design choices that meet those requirements. Although the requirements provide a set framework for your design, there are endless possible solutions. Your mission is to compare your different design ideas and determine which one best meets your requirements. During this process you may discover that some things are more important to you than others, or that some requirements are missing, unnecessary, or incomplete.

Systems Engineering is full of tools to aid you in mapping out your design requirements. One such useful visual aid is a context diagram. The concept is simple: for your system, represent all inputs and outputs as arrows leading into and out of the system. The challenge comes in accurately identifying the scope of your design and how it interacts with the surrounding environment.Context diagrams are key for identifying the most vulnerable parts of any system – the interfaces. If the joining of two systems is poorly understood or designed, both can fail.