1,351
edits
Top-down strategy: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 19: | Line 19: | ||
<br>In real world problems, the dominant situation is non-determinate i.e. it is likely that there is no solution that will fully satisfy the requirements. | <br>In real world problems, the dominant situation is non-determinate i.e. it is likely that there is no solution that will fully satisfy the requirements. | ||
In such situations the basic, top-down, strategy is: propose a possible solution and assess whether it will be satisfactory - or more generally: identify a set of solutions and find the most appropriate one to use. This is the only feasible strategy for non-determinate contexts and may also be needed when the situation is determinate. | In such situations the basic, top-down, strategy is: propose a possible solution and assess whether it will be satisfactory - or more generally: identify a set of solutions and find the most appropriate one to use. This is the only feasible strategy for non-determinate contexts and may also be needed when the situation is determinate. | ||
For examples of non-determinate and deteminate contexts see: ''T[https://www.engineers.scot/office/resources/publications/to-engineer.pdf o Engineer]'' (page 5) and ''[https://www.engineers.scot/office/resources/publications/discipline-ct.pdf The discipline of critical thinking]'' (page 2). | For examples of non-determinate and deteminate contexts see: ''T[https://www.engineers.scot/office/resources/publications/to-engineer.pdf o Engineer]'' (page 5) and ''[https://www.engineers.scot/office/resources/publications/discipline-ct.pdf The discipline of critical thinking]'' (page 2). | ||
| Line 57: | Line 57: | ||
Principles for requirements include: | Principles for requirements include: | ||
* The requirements should be in terms of the function that is to be achieved and should normally avoid reference to solutions. For example for assessing the problem of access across the river Forth in 2007, Transport Scotland did not start with a set of bridge options. They started with the a 'crossing' concept that covered tunnels and causeways as well as bridges. Another example: there is an EU directive for member countries to have a proportion of renwable energy in their electricity systems. Using energy from renewable sources is a solution strategy. The functional requirement is to reduce emissions and the directive should address that reduction, leaving it to member states to decide on the best strategies for achieving it. | * The requirements should be in terms of the function that is to be achieved and should normally avoid reference to solutions. For example for assessing the problem of access across the river Forth in 2007, Transport Scotland did not start with a set of bridge options. They started with the a '[https://engineers.scot/office/resources/papers/iesis-trans157-paper-2.pdf crossing]' concept that covered tunnels and causeways as well as bridges. Another example: there is an EU directive for member countries to have a proportion of renwable energy in their electricity systems. Using energy from renewable sources is a solution strategy. The functional requirement is to reduce emissions and the directive should address that reduction, leaving it to member states to decide on the best strategies for achieving it. | ||
*Do not set a numerical goal unless there is a feasible plan to achieve it . Focussing on a single goal to the detriment of the other goals is a high risk strategy. | *Do not set a numerical goal unless there is a feasible plan to achieve it . Focussing on a single goal to the detriment of the other goals is a high risk strategy. | ||
*While every attempt should be made to establish the full set of requirements at the outset, it is common for new items to emerge as the process develops. The requirements statement and checklist should be kept up-to-date. | *While every attempt should be made to establish the full set of requirements at the outset, it is common for new items to emerge as the process develops. The requirements statement and checklist should be kept up-to-date. | ||
| Line 76: | Line 76: | ||
====Candidate options==== | ====Candidate options==== | ||
The requirements should be divided into negotiable or non-negotiable categories. A candidate option must be able to satisfy the non-negotiable criteria. For example | The requirements should be divided into negotiable or non-negotiable categories. A candidate option must be able to satisfy the non-negotiable criteria. For example non-negotiable criteria should be set for the reliability of an electricity system. A list of candidate options should be drawn up. | ||
====Option assessment==== | ====Option assessment==== | ||
| Line 106: | Line 106: | ||
| | | | ||
|} | |} | ||
A formal approach to comparing the options against negotiable requirements may be used. | A formal approach to comparing the options against negotiable requirements may be used. For example, one can have a table of options against requirements. | ||
For example, one can have a table of options against requirements. | |||
Principles for using an options table include: | Principles for using an options table include: | ||
* | * If possilble, assign a numerical value (e.g. a cost value) in the cells of the table. If not, a qualitative assessment can be made e.g. a score of 1 to 5. | ||
*Seek to create combined options using favourable features from across the set. | *Seek to create combined options using favourable features from across the set. | ||
*Remove options from the table if they are clear losers | *Remove options from the table if they are clear losers | ||
| Line 122: | Line 121: | ||
:"Only accept proposals that have been thoroughly tested: against the requirements; against the inherent risks; against other proposals. If a proposals is shown to be unacceptale, it should be rejected" | :"Only accept proposals that have been thoroughly tested: against the requirements; against the inherent risks; against other proposals. If a proposals is shown to be unacceptale, it should be rejected" | ||
This is probably the most important principle in engineered processes. Neglect of its use is common in autocratic leadership and in government policy-making. It may be that: it is not possible to satisfy all the requirements or that all risks can be eliminated. Also it might not be possible to formulate alternative proposals. But if a less than satisfactory proposal has to be accepted, one should go forward with open eyes about the potential consequences of its adoption. | |||
This is probably the most important principle in engineered processes. Neglect of its use is common in autocratic leadership and in government policy-making. It may be that it is not possible to satisfy all the requirements | |||
===Production=== | ===Production=== | ||