Systems Engineering

The following subheadings list major types of system requirements. Not all would be relevant to a given project, and others besides these might be important to the customer, so it is presented as a starting point for consideration. Each type can include more specific requirement values. The types listed here are linked and somewhat overlapping. For example high reliability and high safety generally go together. Requirements set limits on a design, and overlaps between requirements in effect overlap the range of limits they impose. This is acceptable as long as the designer understands the range of overlaps and interactions among the requirements. A particular design parameter will be governed by the strictest requirement when there is such overlap. An example from civil engineering is that earthquake, wind, and snow loads are all requirements to meet in a building design, and they overlap in that all of them affect the required strength of structural elements.

When broken down to lower levels of the system design, the requirement types and values will become more specific and detailed. Care is needed to maintain logical and numerical consistency across system levels. Requirements, or parts thereof, should not be inserted or dropped at lower levels. Traceability is the ability to follow the chain of requirements across the system levels, and is maintained by documenting how they are connected. This is necessary so you can prove satisfying the lowest level details actually meets the top level system goals. Historically the first two requirement types, performance, and cost, were the primary ones considered. As systems have grown more complex and their outside interactions and side effects become better understood, the number of desirable features, and thus the number of requirements, have increased. This trend is expected to continue in the future.

Aside from the biblical Ten Commandments, requirements are rarely set in stone. Not all of them will be identified at the start of a project. As a result of interaction with the customer and feedback from the design process, they can end up modified. For example, a launch capacity of 10 launches at 100 tons each might be specified for a rocket, and later analysis show that 20 launches at 50 tons each yields lower total cost. The requirements would then be modified to reflect that. At any given time, however, the current set of requirements guides the engineering work. Over time, requirements become more firmly fixed, generally from the higher to more detailed levels in sequence. Changing a requirement forces rework of previous designs. So the cost of changing a requirement grows later in the process, and this tends to exceed any benefit from the change.