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


There might seem to be some justification nevertheless in a purely abstract approach to formulating requirements, as espoused in the DERA book [9], when it comes to combat systems design, given such systems are largely dominated by software issues. For combat management systems certainly, abstract statements of data flow logic can be obtained directly from functional statements of requirement. However John’s comments at a general systems engineering level [4] clearly emphasise the need for a range of solutions to be explored in any complex system design process. Furthermore, most weapon and sensor systems within a warship’s overall combat system fail, or at least have performance drop-offs, due to physical (engineering) aspects receiving too little attention vis a vis the abstract system architecture [13]. It has been the case for some time that, when incorporating combat system equipment into naval combatants, there has been too little regard given to the issues of physical integration and the effects of the extreme physical environment. The author, as a naval architect, had responsibility for integrating weapon systems into a major


ship design [14] and feels the ship design


discipline has abrogated this responsibility to a discipline less focussed on the physicality of the ship and less aware of whole system (warship) cost and ship performance implications.


Less this false god of “Requirements Engineering” be seen as a purely British aberration, it is worth considering the approach in the USA, where the post- WWII emphasis on capability could be said to have originated the “abstract” approach [8]. The US Navy has long advocated a “Total Ship Systems Engineering” approach, which sometimes seems to subsume the naval architect’s or ship designer’s role of co-ordinating or “leading” the whole ship design [15]. Thus Calvano et al [15], although extremely experienced


naval allocation process” ship


designers, feel obliged to define the “functional analysis and functional


in getting “from


customer performance goals to design requirements in a rigorous, complete and traceable way”. This is done through a block-diagram approach so that the “function blocks should represent what must be done, not how to do it”. Thus one can see an emphasis on abstraction, which is counter-intuitive to designers of engineering physical systems (such as ships). It is also considered that this abstraction also presents operational users, trying to spell out what they want, with immense cognitive


capabilities to do future tasks. This identification can only be done by drawing on their


difficulties in identifying appropriate experiences of


operating current real ships and systems, yet they are expected to spell out such capabilities without ostensibly picturing potential physical solutions. I would argue that this abstracting of capabilities is not just false, in that physical solutions are necessary to arrive at non-material (functional) requirements. It is also highly inefficient, in that deriving capabilities without cost and feasibility checks can lead to “dead-ends”. Commitment to such protracted Requirement Engineering has further extended


the front-end decision making for such politically sensitive programmes and, in recent years, too often resulted in programme delay.


If we agree that like the designing of large complex buildings or sets of buildings, such as airports and town centres, the design of naval ships is characterised by the “wicked” nature of the design process [7], where


“formulation of a ‘wicked’ problem is the problem. …setting up and constraining the solution space… is more essential than the remaining steps of searching for a solution.”


Then this explains in part why the solutions. Sorting formulation of


requirements is inherently difficult, but also why this is intimately interwoven with the search for and exploration of


out what a multi-functional,


independently operated vehicle, containing a hundred or more highly trained personnel, might need to do in a very uncertain future can only be explored in terms of possible design options. Furthermore cost, time and risk have to be taken into account (see top “bubble” of Figure 2), in moderating any needs expression by the achievable and affordable. Thus the case for solution exploration is not just to inform the requirements owner but also to ensure the designer is an equal partner in the dialogue. This means dialogue is


then precisely what is meant by Requirements Elucidation.


3. THE BASIS OF SHIP CONCEPT DESIGN STUDIES


If the object of the first phase of naval ship design is that of Requirements Elucidation in tacking problem” of


the “wicked finding the achievable and affordable


requirement, for such a physically large and complex system, then it can be seen to be quite different to the subsequent


phases of design. Those subsequent


sequential phases, typically denoted as Feasibility, Ship Design, Contract Design/Definition and Detailed Design, are essentially about working up the design so that it is shown to be technically achievable and then producible in the built product. To understand better the unique role of the Requirements Elucidation process it is considered worth reprising the description of the concept phase for a putative naval vessel, before showing a range of concept level studies undertaken by the UCL DRC in recent years. These studies were in part exploring the characteristics of this crucial


front end of the design process for such physically large and complex systems.


At this point it is worth stating a truism, that each ship project is different in its objectives and constraints from all others. Thus the approach advocated in this paper is seen as primarily justified for major naval ship programmes, despite there still being distinct advantages in its adoption for lesser projects. However in the latter cases, the


timescales and scrutiny process are considerably shorter, often to meet a more limited and,


A-26


©2011: The Royal Institution of Naval Architects


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