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.2 Measures of Effectiveness
Desired features are often in opposition. For example, higher performance and reliability often come at the expense of higher cost. There are also alternate designs which have different amounts of each feature. Establishing Measures of Effectiveness is the quantitative method to account for these disparate features at the level of the whole system. Like requirements, they are derived from customer desires. In this case it is what features would be "better" when comparing one design over another. Since different features typically have different units of measurement, they need to be converted to a common measuring scale. This is done by formulas that convert each different value, such as cost or performance, to a score. These scores are given relative weights based on their importance to the customer. The weighted measures can then be used in a single mathematical model or formula to determine "better" as a total score, when the component values vary across different designs.
The value scale is often in a range such as 0 to 100%, or 1 to 10, but this is arbitrary. What is more important is a definite conversion from a measurable feature to a scoring value, and the relative weights and method of combining them to a total score. As an example, a value of 0% might be assigned to a payload of 15 tons, and 100% to a payload of 45 tons, with a linear scale in between, and payload given an importance of 30% in the total score. The total scoring system becomes a mathematical model of the customer's desires for the system. Getting a customer to define "better" in such detailed numerical form is often difficult, because it removes their freedom to choose what they personally prefer in a design in spite of the engineering solution. It is necessary, though, if you really want an optimal answer. At the least this process makes it obvious when the customer is over-riding the engineering process.
It should always be kept in mind that a particular design solution may not be "good enough" in terms of of it's measures when compared to existing systems. This can be found by including the existing system as one of the alternative designs being scored. In that case the proper answer is to stop development of the new system and stay with the existing ones. Often the cause is not enough performance improvement relative to cost, but other measures can result in a decision to stop.