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.