Systems of Primary Elements

At this point, we should recall our description of stakeholder requirements in Sec. B4.2. There we identified a subset of the stakeholder requirements, the functional requirements, as those that define the service that is, what the stakeholders want to receive (and for which they are willing to pay and/or invest) and the conditions under which it is to be provided, without any reference to any physical entity, or plant, that provides it. A further subset, the performance requirements, placed requirements on the performance of the plant, such as its reliability, safety, and levels of emissions. 

Through the activities of architecting and functional analysis, described in the previous chapter, we identify the functions that the plant must have in order to meet the functional requirements, and we express this in the form of a system of functional elements. These are the primary elements. However, we now need to realise that the functions we, as engineers, determine will be required to provide the service will generally include a number of functions that are not directly involved in providing the service, and in conformance with normal practice we subdivide the system of primary functional elements into three subsystems, 

The reasons for this subdivision are that the skills and knowledge of the people working in these three areas of a plant are different, and it is important that already at this early stage of a project this is acknowledged and that the best available knowledge is brought to bear on the design. 

The operations system has been, and will continue to be, the main focus of our design in the functional domain, because it is the system whose functional parameters must include the parameters defining the service (and which we generally call service parameters without differentiating between what they belong to) it is this system that generates the revenue, and it is therefore this system we optimise initially, as we shall see in the next chapter. As such, it is the system to which the other two must relate, and the structure of this system forms what we already referred to, in Sec. C4.6, as the skeleton of the functionality. 

The secondary elements describe aspects of the functionality that are additional to the actions described by the primary elements, and they arise out of two very different groups of requirements. Some secondary elements are required in direct response to corresponding requirements in the stakeholder requirements a typical example is a stakeholder requirement for dependability of the service, which then needs to be reflected in a requirement on the reliability of the system of primary elements. Other secondary elements are required as inputs to the primary elements, and again, reliability (or availability) might be required as input to a revenue element in order to be able to optimise the ROI, even if there is no explicit stakeholder requirement for reliability. Another example of this is cost there may not be any direct requirement on the cost, but a requirement for optimising the ROI will demand that cost is included in the description of the functionality. 

---