Deriving and Allocating Errors in a System

We take now as a third example of deriving and allocating requirements that of sighting and pointing at a target in a shipboard environment. We assume that the stated requirement for the system is that the sighting to the target have a maximum permissible error of one-half of a degree, which is equivalent to 0.00873 radian. We further break down this error into three fundamental error sources:

1. Error in pointing by a human (operator error)

2. Error in the pointing instrument (instrument error)

3. Error in mounting the instrument to a platform (platform error)

The issue is then to derive pointing requirements (maximum errors) for these three error sources and the systems they represent.

This situation is depicted in Figure 8.4. Under a model that claims independent additive errors associated with the random variables that represent the error sources, the total root-mean-square (rms) error is related to the subordinate errors by the relationship:

where c is the rms error (standard deviation) and its square is the variance

Figure 8.4. Derived and allocated pointing-error requirements.

of any error distribution. The derived maximum errors, as determined by the systems engineer, are

Maximum human (operator) error = aO = 0.4 deg Maximum instrument error = aI = 0.2 deg Maximum platform error = aP = 0.224 deg

These then represent a consistent set of derived error requirements that may be utilized in the design of the various subsystems. Because one of these ''subsystems'' is the human operator, we have to verify that such a person is able to point the instrument within the designated error limits. If this is not possible, then there has to be a further rederivation of errors such that the overall pointing error requirement is satisfied. This may turn out to be a long and difficult process, but it is necessary to meet the overall system requirement.

We further note that the algorithm used in this error calculation is different from that used in both the weight example (Section 8.7.1) and the reliability example (Section 8.7.2). The error calculation called for a summation of the squares of the rms errors, equivalent to the sum of the variances of the independent error-source variables. The error, in this example, is also associated with a ''one-sigma'' value, another choice that might be made by the systems engineer. Here again, the nature of error algorithms must be part of the body of knowledge of the systems engineer in order to carry out this derivation and allocation in a correct manner.


The preceding discussion has emphasized the importance of requirements analysis and allocation and the problems associated with requirements. Al though customer or user requirements are the touchstone for the systems engineering effort, it is also true that problems with requirements suggest that certain requirements be negotiated and changed. Living with requirements that are ambiguous or cannot be satisfied, in the long run, decreases the likelihood of success of the project and its systems engineering activities. For those requirements in that category, the PM and the CSE must enter a process of discussion and negotiation to resolve any and all problems. This means that despite the perspective that requirements are often taken as inviolate, problems with requirements must be solved.

To some extent, the matter of changing or updating requirements has been acknowledged. One such manifestation is in the so-called ''spiral model'' for software development. This model explicitly revisits the requirements several times to deal with problems in this domain. This is a step forward in the context of the overall subject of software development and engineering.

Another step that has been taken to deal with requirements issues is that of having a representative of the user or customer be part of the systems engineering group. In this way, a direct and immediate link is established with the customer, who is then able to respond to the issues that might be raised with respect to interpretations and changes of requirements. Closer linkages between the project and engineering activities and the customer is also a major step forward in trying to deal realistically with what has been a problem area for many years.

Finally, requirements relative to software have constituted large parts of our systems as they have leaned more heavily on software solutions. Therefore, software requirements specification and analysis have received a great deal of attention in recent years [8.12].

In summary, the systems engineering team must treat requirements analysis and allocation as an extremely important part of the systems engineering process. It must also be prepared to resolve difficulties with requirements and not necessarily accept poor requirements as fashioned in concrete. A full and open dialogue with the customer with respect to such issues helps to increase the chances of success of the project.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment