System engineering can best be explained as coordinating multiple tasks within the two disciplines of engineering and engineering management. This paper highlights the systems method of coordinated tasks and its relevance concerning current and future business system life cycles: concept, design, planning, testing, optimization, and deployment. It defines the boundaries necessary for a robust life cycle and analysis to occur.
3. Requirements Analysis
3.1 Requirements Definition
The highest level general desires are first converted to specific measurable features and values called System Requirements. These are later broken down into more detailed lower level requirements, which are assigned to logical elements of a system called Functions to perform. The assignment ensures that somewhere in the system all the top level goals are met. At the most detailed level a subset of the lower level requirements are assigned to a single function box. This now becomes the detailed design conditions for that function. Assuming the analysis has been carried to a low enough level, the detailed design of the element that performs the function can then be done with a reasonable effort.
The first step in requirements definition is documenting the original desire or need of the customer in as much detail as they can provide. We will use as an example the Apollo program to land humans on the Moon. That was expressed by President Kennedy as a well known goal with a deadline. That very general statement was not sufficient to design the hardware. The key task is to put all the requirements in forms that can be measured so that you can tell when you meet them. Experience shows if a desirable feature or parameter is not expressed and measured, it will not happen as desired. An example of this failure is the Space Shuttle Program. The original goal was to fly 60 times a year. Given a fleet of 4 Orbiters, each one had to fly 15 times a year, or one launch per 24 days. Subtracting 7 days on orbit and one day before and after flight for launch preparations and post-landing recovery, that leaves 15 days to complete ground processing. The stated goal was thus 160 hours for ground processing, composed of 2 shifts (16 hours) x 10 work days over two weeks, thus 14 days. This goal was expressed, but it may not have been included in the system requirements, and it definitely was not allocated to lower tier hardware and tracked at the lower levels like hardware weight was.
Only after the Shuttle was already flying was it noted that ground processing was taking too long, and efforts started to reduce it. At that point it was too late to make any fundamental changes in the design, and so ground processing never got below about 800 hours, about 5 times the original goal. This was a major contributor to the Shuttle never reaching its intended flight rate. In order to have reached their goal of 160 hours, processing time would have had to be allocated to sub-systems, such as landing gear or maneuvering thrusters, and then each subsystem designed to meet it's assigned time. Conversely to processing time, weight has always been a tracked parameter in aerospace systems, since airplanes cannot function if they are too heavy. The Space Shuttle had very detailed weight targets and a tracking system by component, with monthly reports. It more or less reached its design payload, which is the 1.5% of available launch weight remaining after the vehicle hardware and fuel are accounted for.
This example emphasizes why desired features must not only be stated quantitatively, but passed down for engineers to meet in detailed design, and tracked so you can tell if you are going to meet them. Measurable parameters can be a simple yes or no, for example "Does this airplane design meet FAA regulations?", or it can be a numerical value, range of values, table, formula, or graph indicating the range of acceptable values for that system characteristic.