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, October 18, 2006

Requirements Management

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:

      1) No orphans -- Each requirement needs to link back to either a higher-level one or an objective
      2) Hierarchy – All requirements at a given level must describe the same system. The size requirements of your rainwater cistern (if you have one) belong at a lower level than your basic water requirements.
      3) Baselining – Each level in the hierarchy should be frozen against further modification before advancing too far. This prevents you from constantly reworking all of your requirements and helps force you to ensure the “goodness” of the higher-level requirements. The common rule of thumb is that you can work up or down one level from your current one, but the higher levels must be frozen before continuing. (Example: Requirement 2.1.1 for 280 lpd of potable water is the highest-level; the next could be regarding the water system temperature; the next level requirement would be regarding a specific component of the system (say the cistern). In this example we can’t move on to the third level until we baseline Requirement 2.1.1)
This doesn’t mean you can never change the higher-level requirements, it just gets harder as your design matures.

As always, strive to keep specific design solutions out of your requirements. It can be difficult not to design, but try to focus on defining your needs before figuring out how to meet them. You design will be so much better if you resist the temptation.


Post a Comment

<< Home