Trans RINA, Vol 153, Part A1, Intl J Maritime Eng, Jan-Mar 2011
particular, this diversity is addressed by the author’s research team at UCL. It is then sensible to reinforce that general outline by describing a wide range of recent ship concept design studies. This is a change from the 2003 paper, which considered the initial design of such PL&C systems through the specific example of the FSC. This change is done to show the variety of studies typical of early stage ship design and that they all exhibit, to a greater or lesser extent, the characteristics identified in the approach designated by Requirements Elucidation. This approach is seen to be the fundamental objective of early stage design of such PL&C systems, for which the characteristics of this phase of design have previously been denoted as “wicked” by architectural and planning theorists [7].
From consideration of these diverse
examples it is possible to consider what is required to be done in initial design to enable a major project to proceed into actual design evolution. The author has identified five characteristics, which are seen as clear indicators of the information necessary at the end of the concept phase in order to proceed into the remainder of the ship design process. In addition the issue of identifying the style of the emergent solution is seen to be critical and requiring a more descriptive concept definition than has historically been deemed sufficient. Thus it is possible to conclude what
the desired Requirements Elucidation
process requires, by way of an initial design synthesis, and why this approach is totally compatible with good project management (and systems engineering) practice.
2. THE ORIGIN OF REQUIREMENTS ENGINEERING
The origin of the notion of Requirements Engineering within a systems engineering approach would seem to lie with a change in emphasis in the defence acquisition field post war initiated by the US military. That was to a focus on military capabilities rather than equipment performance [8]. This was strongly enshrined in UK defence
procurement with the Smart Procurement
Initiative in the late 1990s and was illustrated in the 2003 paper with two figures [1]. These showed the make up of the key “non material solution specific” Requirement Engineering products, the User Requirements Document (URD) followed by the System Requirement Document (SRD). Their relationship to “System Design” was spelt out
by van Griethuysen feedback. (2000) in the systems
engineering iconic “waterfall diagram”, which (drawn from INCOSE’s 1991 statement) showed a sequence of the URD then the SRD and finally System Design, without any
highlighted in the 2003 paper by drawing attention to the URD and SRD being in Procurement principles through expressed and “engineered” ...
being
avoiding material solutions” [1]. So where
did this strong prohibition, reference to material solutions, in deriving the
capabilities needed by the user and, even more bizarrely, in producing the SRD, as the statement of the “system
This approach was further accordance with Smart (and) assiduously against any
“functionally
engineers ‘own’ requirements” [9], actually come from? The text quoted as the
authority in the Smart
Procurement process was the book entitled “Systems engineering – coping with complexity” written by four co-authors Research
from the (then) Defence Evaluation and Agency (DERA) systems and software
engineering team. Chapter 3 of that book, went so far as to be headed “Defining the solution in abstract” and then stated this was “showing what the system will do but not how it will be done.” The book’s authors then clarified that the writers of a SRD as designers, planners and systems engineers
(note not the end users
or
requirements owners) “write requirements that do not necessarily constrain the solution …(the SRD being seen) primarily as an artefact needed for development” [9].
It would therefore seem that the origin of such an approach to “Requirements Engineering” lies clearly in software engineering where both the appropriateness of specifying user and system requirements in abstract has some logic and the focus on “development” prior
to
design is consistent with software production. However it is wholly inappropriate to then read this across to material
products, such as complex constructions
constituting warships and their land based equivalents of large-scale physical infrastructure projects. Interestingly, Brook (one of the co-authors of the DERA book and subsequently Director of Systems Engineering in DERA) in an influential paper in 2000 [10], summarised the “basic systems engineering processes” with a diagram reproduced below as Figure 1, which clearly shows the three steps (for URD, SRD and “System Design”) as a “trade off
triad” “that may have to be traversed in a
number of iterations” and very importantly the arrows linking the three are not sequential but in both directions between all three elements. Furthermore Brook then denotes System Design as “Architecture – High level design” which is said to define the principal components and an overall architecture: terms with which a naval ship designer would feel entirely comfortable, as descriptive of ship architecture [11].
This more interactive set of processes is also reflected in the much more realistic ‘waterfall’ model, also reproduced here, as Figure 2. This version was the centre piece of the Royal Academy of Engineering’s 2007 guide written by the Academy’s Working Party on Integrated Systems Design, consisting of the UK foremost systems engineers. The Guide entitled “Creating systems that work:
Principles of engineering systems for the 21st
century” [12] gives six principles for integrated system design, the third of which “Follow a disciplined procedure” is illustrated with Figure 2. In this procedure the start of the whole process is absolutely not a requirement neatly enshrined in a massive URD but another interactive triad, shown in the first “bubble” and is much more inclusive and less prescriptive. The three interacting elements in that first bubble are “what do the stakeholders want?”; “what are the possible solutions?”;
A-24
©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