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.
Rather than tie each requirement directly to an objective, we now recognize that some requirements meet multiple objectives, provide an link between objectives, or are otherwise necessary to ensure the final product will function satisfactorily.
The structure for capturing all of the various types of requirements we want will be generalized below. Note that every subsystem will follow this same organizational scheme.
1.0 System-wide Requirements
1.1 Functional Requirements
1.1.1 Input Requirements
1.1.2 Output Requirements
1.1.3 Interface Requirements
1.2 Non-Functional Requirements
1.2.1 Suitability Requirements
1.2.2 Physical Requirements
1.2.3 Technology Requirements
1.2.4 Standards and Protocol Requirements
1.2.5 Cost Requirements
1.2.6 Schedule and Phasing Requirements
Functional requirements denote how the system interacts with its environment. Every input, output, and control should have at least one requirement. Interface requirements refer to physical attributes a system needs for interacting with the environment and the inputs/outputs. See context diagrams for help on determining inputs and outputs.
Suitability encompasses the “-ility” requirements we’ve discussed before, such as maintainability and reliability. It also includes usability, survivability, safety, security, learnability, testability, and extensibility.
Technology requirements are extremely important when designing for Peak Oil, but must be carefully considered as they can constrain the design. These requirements can limit creativity and so should be employed only when absolutely necessary.
Standards and Protocols can be any government code or some other standardized practice to which you must adhere.
Next we’ll work on updating the example project and show solid examples of each type of requirement.
Delicious
Digg
Reddit
Magnoliacom
Furl
Technology Requirements
I have mixed feelings about technology. On the surface technology would seem to open up doors and expand creativity, at least in the beginning. When looking down the road however, into the future, technical equipment and supplies could become difficult if not impossible to maintain, repair or replace. Do I understand your concerns about technology correctly?
Yes
I think you grasped my concerns about relying on technology correctly. Although it's not just high-tech maintenance after Peak Oil that I caution against, but also planning on using technology with a low Technology Readiness Level, planning to acquire technology that becomes unavailable, or technology that's just plain too expensive. There are all sorts of trade-offs that need to be considered.