NOTE: Make sure you read the first three posts (in order!) before tackling the rest, or it could be confusing: Post 1 is Designing the future, Post 2 is Setting up the problem, and Post 3 is Estimating basic requirements.


Wednesday, August 09, 2006

Estimating basic requirements

Okay, I promise this is nearly the last boring post before really diving into design strategies and solutions. I’ll try to make this as interesting as I can, but bear with me – this is important!

Now that we have satisfactorily defined our example problem, we can start figuring out what tangibles we need. This process is known in Systems Engineering-speak as requirements definition.

Requirements can be a complicated business, in identifying them, organizing them, and even properly writing them. I will illustrate proper requirement definition with a few examples, but I will not go into much depth on everything that goes into effective requirements. You can learn that much more effectively by reading some of the references I cite or taking a Systems Engineering class. That said, I can’t emphasize enough how important it is to define clear requirements for your project, whatever its scale. You need to have a clear understanding by all parties involved, using requirements that can’t be misinterpreted, or you risk disaster.

Let’s pick one of the objectives from the last post and start figuring out some requirements to satisfy it. Objective 3.1 states “The community shall produce enough food for four people.” That seems like a good place to start.

According to the USDA, the food intake requirement per person per day is about 2100 calories. To meet our objective of producing enough food for four people, we can write Requirement 3.1.1: “The community shall provide no less than 8400 calories of food per day.”

Notice the form of the requirement: it says nothing about how we will provide that food. It never says anything about farming, livestock, hunting, gathering; it says nothing about food storage; it says nothing about greenhouses or any sort. It says only what the designed community must provide in order to be considered a success. This is an example of a high-level requirement. As we develop a solution, we will start making design decisions and lower-level requirements will start to fall out. (Note: As we move into lower levels, the requirements will change from “The community shall…” to “The garden shall…” or “The storeroom shall..”, etc.)

For now, Requirement 3.1.1 looks like it meets Objective 3.1 well enough. This is an iterative process, so we may change it as we develop a better understanding of our true requirements (i.e. the two children don't need 2100 cal/day at the outset, so maybe the requirement could start small and ramp up as the kids' needs increase). I’m going to leave it at that tonight and continue discussing requirements in the next post. Then it gets fun, and we can start tossing around design solutions and strategies.


At 10:36 PM, Blogger casecore said...


At 12:20 AM, Blogger Brother Kornhoer said...

Nice intro. BTW, don't I see you on TOD? Any places in Florida you see working toward community-wide solutions? I'm in Tallahassee - Brother Kornhoer on TOD.

At 12:21 AM, Blogger Brother Kornhoer said...

Also, you might want to allow anonymous comments, as I had to create a blogger account to comment.

At 8:07 PM, Blogger PeakEngineer said...

Good call on the anon. comments. Done.

At 8:13 PM, Blogger PeakEngineer said...

Yep, I read TOD pretty regularly and post there sometimes. There are some communities forming in Florida (I think there was at least one guy from Miami on The Oil Drum) but not much in my area (central Florida). Personally, I don't see lower Florida as being a safe place long-term -- too few resources, too close to sea level, too prone to hurricanes, and too many people to be sustainable.

At 1:23 AM, Blogger bytestyle12 said...

Everybody normally understands the down sides of internet generally and online gaming specifically.
Cadillac Eldorado Air Conditioner Compressor


Post a Comment

<< Home