Trans RINA, Vol 153, Part A1, Intl J Maritime Eng, Jan-Mar 2011


constrain the task of tackling the, essentially, wicked problem.


Thirdly, decisions have to be made in coming to the conclusion of


this largely divergent and exploratory


phase, to then proceed into “engineering design proper”. These normally consist of which one, or possibly two, outline design concepts, balanced to the limited extent appropriate to inform these early decisions, are to be taken forward. This is classically a “trade-off” process, where distinctly different options have to be assessed, despite their inevitably different attributes and levels of uncertainty. There are tools available to assist in decision-making but there is a risk in using them blindly, especially if the process has not been recognised as “wicked”


and full of (potentially) unappreciated


constraints. So there is the need to ensure that a comprehensive and challenging concept design process is being conducted. This has to be done before trade-off studies are undertaken and is essential to inform any quantitative trade-off process. Furthermore, such numerical


trade-off studies should be primarily


undertaken to provide enlightenment rather than being the sole basis of decision-making, since this can too readily be reduced to just ship cost arguments.


Part of the nature of this wicked, decision-making and complex trade off process is that choices have inevitably been made as to the “style” of the various design concepts investigated. Thus the next crucial aspect is identification of style. What importantly this does, in the concept phase, is to bring to the fore many issues, which are of major concern to the ship operator. These were either hard to recognise in the traditionally narrow concept exploration, or not considered addressable by the traditional naval architectural


studies. In what has been argued is a paradigm shift due to advances


in computer graphics [22, 17],


design concerns, especially those dealing with the human factors aspects of PL&C systems, can now be readily addressed in ship concept studies – as examples in the previous section indicate.


The final aspect, not surprisingly, is that of Requirement Elucidation, which brings together much of the first four considerations but strongly emphasises that this


first


phase of design is not about a blinkered rush into the subsequent design phases but, rather, is a process of elucidating what is required. Furthermore, requirements elucidation can only be done properly through a dialogue between the naval staff and the concept ship designer. This needs to be open and un-constrained so both participants


help the other in the decision-making


necessary to cope with the wicked nature of the process. That the process must be done in a manner that uses the design skills of


the ship designer should be all too


obvious. Furthermore, ship concept designers have an obligation in this dialogue to encompass the exploration of style issues, many of which are beyond their (S4) comfort zone and this is seen as a significant


consequence of the paradigm shift. This consideration then leads on to a final set of statements as to what must characterise the output from concept design tools, if they are to assist the ship designer, in the complex acquisition environment for naval vessels, to properly undertake requirements elucidation:


 Believable solutions, that is to say solutions which are both technically balanced and sufficiently descriptive;


 Coherent solutions, which mean that the dialogue


with the customer and other stakeholders should be more than merely a focus on numerical measures of performance and cost, by including a comprehensive visual


representation (noting that SURFCON


provides considerably more than an artist’s impression of the outside of the ship);


 Open methods, in other words the opposite of a ‘black box’ or a rigid/mechanistic decision system, so that the description is responsive to those issues that matter to the customer,


or are capable of being elucidated by the designer from customer/user teams;


 Revelatory insights, in particular identifying likely design drivers, early in the design process, to aid design exploration in initial design and beyond;


 A creative approach, not just as a ”clear box” but actually encouraging “outside the envelope” radical solutions and a wide exploration to boundaries.


design push the and requirement


requirement elucidation


All this is consistent with the message of what is needed for effective requirement elucidation.


input to concept design ‘softer”


6. CONCLUSIONS The conclusion of this paper is that Requirements


Engineering with a sequential and non-material specific set


of outputs is poor systems engineering. Rather


Requirement Elucidation, as spelt out with reference to actual concept studies, is the correct aim of the front end process of acquiring Physically Large and Complex Systems, typified by naval vessels. It is recognised that this means the pre-feasibility design phase of


such


systems is not straight forward and will require further development in methods, tools and designer capabilities. Furthermore, only this requirements elucidation mind set is seen to provide a basis for improving ship acquisition in the demanding times ahead.


7. ACKNOWLEDGEMENTS


The design studies outlined in Section 4 were largely funded by government, including research grants, and by industry, whose support is gratefully acknowledged. Most of the specific designs were produced by the author’s senior research associate, Dr Richard Pawling, whose contribution to the development of the DBB approach is particularly acknowledged.


©2011: The Royal Institution of Naval Architects A-37


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64  |  Page 65  |  Page 66  |  Page 67  |  Page 68  |  Page 69  |  Page 70  |  Page 71  |  Page 72  |  Page 73  |  Page 74