Introduction: Relating Requirements and Architectures - Springer Link

Chapter 1

Introduction: Relating Requirements and Architectures J.G. Hall, J. Grundy, I. Mistrik, P. Lago, and P. Avgeriou

This book describes current understanding and use of the relationship between software requirements and software architectures. Requirements and architectures have risen to be preeminent as the basis of modern software; their relationship one to the other is the basis of modern software development process. Their case was not always clear cut, and neither was their preeminence guaranteed. Indeed, many tools and techniques have held the spotlight in software development at various times, and we will discuss some of them in this chapter. Now, however, it is clear that requirements and architectures are more than just software development fashion: used together they have helped software developers build the largest, most complex and flexible systems that exist today. They are trusted, in the right hands, as the basis of efficiency, effectiveness and value creation in most industries, in business and in the public sector. Many fast-moving areas, such as manufacturing, chemical and electronic engineering, and finance owe much of their success to their use of software! It has been a virtuous spiral with the relationship between requirements and architectures driving progress. In the light of this, this chapter reflects on two strands to which the relationship in question has made a defining contribution. The first strand considers software developers’ management of growing code complexity, a topic that lead to requirements and architectures, as well as motivating the need to understand their relationship. Specifically, we look at systems whose context of operation is well-known, bounded and stable. Examples are taken from the familiar class of embedded systems – for instance, smart phone operating systems, mechanical and chemical plant controllers, and cockpit and engine management systems. As will be clear, embedded systems are by no means unsophisticated, nor are the needs that such systems should fulfill simple: some, such as air traffic control, contain complex hardware and exist within complex socio-technical settings. Indeed, embedded system complexity has grown with the confidence of the software developer in the complexity of the problem that they can solve. For the purposes of this chapter, however, their P. Avgeriou et al. (eds.), Relating Software Requirements and Architectures, DOI 10.1007/978-3-642-21001-3_1, # Springer-Verlag Berlin Heidelberg 2011

1

2

J.G. Hall et al.

defining characteristic is that the context of the system is more or less stable so that change that necessitates redevelopment is the exception rather than the norm. The relationship between requirements and architectures for such systems is wellknown – it is recounted in Sect. 1.1 – and the uses, efficiency and effectiveness of it is the topic of much fruitful research reported elsewhere in this book. The second strand deals with systems for which a changing context is the norm, and that are enabled by the flexibility – some might say the agility – of the software development process that links requirements and architectures. It describes how developers work within a volatile context – the domain of application – and with the volatile requirements to be addressed within that domain.1 Software systems typical of this class are those which underpin business processes in support of the enterprise (whence our examples), with problem volatility being simply the volatility of the business context and its needs. The relationship between requirements and architectures in the face of volatility is less well explored and we look at the source of some deficiencies in Sect. 1.2. New thinking, techniques and tools for improving the efficiency and effectiveness of the treatment of volatility is the topic of other leading-edge research reported elsewhere in this book. Complexity and volatility are now known to be key developmental risk indicators for software development (see, for instance, [1]). And it is the successful treatment of complexity and volatility that places software requirements and software architectures as preeminent in linking problem and solution domains: as they are the key in the management of developmental risk, so most mainstream current practice is based on their relationship. This chapter is organised as follows: after this introduction, we consider the rise of complexity in systems, providing an historic perspective that explains the current importance of the relationship between requirements and architectures. We consider next the rise of volatility in the light of the widely held critique of software project failure. The last section makes two observations, and from them motivates the continuing and future importance of the relationship between software requirements and architectures.

1.1

The Rise of Complexity and Volatility

The themes of this chapter are the developmental management of complexity and of volatility. Figure 1.1 (with Table 1.1) classifies various example systems according to their characteristics. In the figure, software complexity (measured by the proxy of lines of code2) is related to context volatility.

1

We note that context and requirements may change independently; as they define the problem that should be solved, we refer to problem volatility as indicative of these changes. 2 The precise details of this relationship between complexity and lines of code have been subject to many debates over the years; we do not replay them here.

1 Introduction: Relating Requirements and Architectures

3

Fig. 1.1 Relating of requirements and architectures, the rise of complexity an volatility

The line labelled ‘System limit’ in the figure provides a bound based on the observed laws on the growth of computing power. The most relevant (and most widely known) is Moore’s observation that, essentially, computing power doubles every 2 years [2]. Also overlaid on the figure are various ‘Developmental structuring mechanisms.’ These are referred to in the text, with the figure serving to delimit the approximate scope of their applicability.

1.1.1

The Rise of Complexity

Manchester University housed the first stored program computer, the Small-Scale Experimental Machine (SSEM in Fig. 1.1) – aka Baby – which ran its first program on 21 June 1948. Baby’s first run was on a 17-line program3 that calculated:

3

See [3] for an intriguing reconstruction of that first program, together with a transcript of the notes accompanying its design.

CICS72-91

SAP MAC OS

MS OFFICE

Android

Android: the open source handheld operating system Microsoft Office software suite, the core of many organisations information strategy SAP enterprise resource planning software www.sap.com Apple Macintosh operating systems, version 10.4 IBM CICS (Customer information control system). The line represents its beginnings in 1968 until 1991, when complexity had grown to 800,000 loc.

Table 1.1 Details of the systems referred to in Fig. 1 Fig. 1 Ref Description First program run on the Manchester small-scale Baby experimental machine, aka Baby The transfer control protocol/internet protocol TCP/IP software stack POS Java point of sale open source system Quake III Arena software, a multiplayer computer Quake 3 game released December 2, 1999 F-22 Raptor □ 787 Dreamliner □ Mercedes A comparison of avionics’ and car management CMS system. The 5ESS switch is a class 5 telephone electronic 5ESS switching system sold by Alcatel-Lucent NT3.1 Windows NT 3.1 operating system

www-01.ibm.com/software/htp/cics/35/

en.wikipedia.org/wiki/5ESS_switch en.wikipedia.org/wiki/Source_lines_of_code www.gubatron.com/blog/2010/05/23/how-many-lines-ofcode-does-it-take-to-create-the-android-os/ blogs.msdn.com/b/macmojo/archive/2006/11/03/it-s-allin-the-numbers.aspx jshurwitz.wordpress.com/2007/04/30/how-does-sap-turn250-million-lines-of-code-into-modular-services/ en.wikipedia.org/wiki/Source_lines_of_code

spectrum.ieee.org/green-tech/advanced-cars/this-carruns-on-code

www.slideshare.net/ericvh/hare www.fileguru.com/apps/point_of_sale_java_source_code ftp://ftp.idsoftware.com/idstuff/source/quake3-1.32bsource.zip

[3]

Source: (last access: 27 March 2011)

4 J.G. Hall et al.

1 Introduction: Relating Requirements and Architectures

5

[. . .] the highest factor of an integer. We selected this problem to program because it used all seven instructions [in the SSEM instruction set]. It was of no mathematical significance, but everybody understood it. Tom Kilburn [4]

This trivial problem was, arguably, the beginning of the modern information age. At that time, a simple software process was sufficient: the program above was simply crafted by inspection of the problem and debugged until it was correct. As higher problem complexity was encountered, code complexity increased. One response to the need to manage higher code complexity was to provide richer and richer structures within the programming languages in which to implement it. High-level programming languages were developed to provide greater abstraction, often with concepts from the problem domain allowing more complex code to service more complex problems. There was a steady trend in sophistication leading to the ‘fifth-generation languages’ (5GLs) and ‘domain-specific languages.’ However, in 1992, Perry and Wolfe [5] brought ‘elements,’ ‘forms’ and ‘rationale’ together and so placed the new topic of ‘software architecture’ at the heart of code design. For, with them, Perry and Wolfe captured the repeated code and thought structures used to code and to justify code. Shaw and Garlan’s book [6] laid the groundwork for the development of software architecture as a discipline. From our vantage point and by their lasting popularity and utility, architectures (in their various guises) are the correct abstraction for software: they are programming language independent and serve to structure large systems4 [7]. With architectures came a growing confidence in the extent to which complexity could be handled and this led to a need for techniques and tools for managing complex (if stable) problem domains. Even though the term software engineering had been defined in 1968, coincident with the rise of architectures was a growing realisation of the importance of an engineering approach to software. The traditional engineering disciplines had already been a rich source of ideas. The successful construction and manufacturing process model has, for instance, inspired the early software process model. today known as the Waterfall model, as illustrated in Fig. 1.2. With architecture at heart of program design, software requirements began to be explored through software requirements engineering (for instance, [9]) which managed problem complexity through phases of elicitation, modelling, analysis, validation and verification. As required by the waterfall, software requirements engineering led from system requirements to software requirements specifications on which architectural analysis could be performed. Things did not go smoothly, however; already in 1970, Royce [8] had suggested an amended model based on his extensive experience of the development of embedded software ‘[. . .] for spacecraft mission planning, commanding and postflight analysis’ which had found it wanting. In particular, Royce saw the need to

4

Their rise has also been coincident with a waning in the popularity of high-level programming languages; always wary of cum hoc ergo propter hoc.

6

J.G. Hall et al.

Fig. 1.2 The traditional ‘Waterfall Model’ for software: a successful development process from construction and manufacturing (Adapted from [8])

iterate between software requirements and program design (and between program design and testing): for software, the early stages of development could not always be completed before commencement of the later stages. It was Royce’s enhanced model, illustrated in Fig. 1.3, that inspired a generation of software processes. And it is this model, and its many derivatives, that characterise the massively successful relationship between requirements and architectures, at least for embedded systems.

1.1.2

The Rise of Volatility

The waterfall model made one other assumption that is not true of software, which is that a stable problem exists from which to begin development. It is the lifting of this assumption that we explore in this section. Of course, there were many early business uses of computers: a very early one started in 1951 when the Lyons5 Electronic Office (LEO, [10]) was used for order control and payroll administration. These early applications typically involved scheduling, reporting and number crunching and, although they provided many technical challenges to be solved that were complex for that time, what amounts to

5

J. Lyons and Co. A UK food manufacturer in the mid 20th century.

1 Introduction: Relating Requirements and Architectures

7

Fig. 1.3 Royce’s updated waterfall for embedded system development (Adapted from [8])

first mover advantage [11] meant Lyons enjoyed a stable environment in which to explore their business use of computers. The wish for more sophisticated business computing use meant developers dealing with the volatility of the business world. Any connection between the informal organisational world and the (essentially) formal world of the computer [12] must link two volatile targets: the world of enterprise and the world of technology. As the move from real-world to formal world is unavoidable [12], development must both initially cross and, as the needs exist in the real-world, subsequently recross the boundary as development continues. Due to volatility, the resulting relationship between requirements and architectures is an order of magnitude more complex than for stable systems, and the treatment of it offered by traditional techniques, such as those derived from Royce’s processes, are increasingly seen as inadequate. Indeed, software development in the face of such volatility is now recognised as one of the greatest challenges it faces. Unfortunately, only the magnitude of the challenge is understood fully: a recently published study of 214 of large IT Projects6 [13] concluded that 23.8% were cancelled before delivery, with 42% (of those that ran to completion) overrunning in time and/or cost. According to the study, the total cost across the European Union of Information Systems failure was estimated to be €142 billion in 2004.

Modally, the projects were in the €10–20 million range.

6

8

J.G. Hall et al.

With the best minds on the problem of developing software in volatile contexts, exploration is in progress; indeed, a sizeable proportion of this book describes state of the art thinking for this problem.

1.2

The Future of Requirements and Architectures

It is, of course, possible to imagine that the changes that are wrought to software processes in response to volatile contexts will make redundant both requirements and architectures, and so knowledge of their relationship. It may, for instance, be that the need to treat volatility will lead back to high-level language development. There are already some small trends that lead away from requirements and architectures to self-structuring or multi-agent systems that, for instance, learn what is needed and then supply it autonomously. Who knows from whence the breakthrough will come! There are, however, a number of observations of the systems we have considered in this chapter that lead us, with some certainty, to the conclusion that requirements and architectures will remain topics of importance for many, many years, and that their relationship will remain the basis of mainstream, especially organisational, software development. Firstly, even if change is the norm, the scope of change in organisations is not the whole organisational system. For instance, there are general organising principles – the need for user to access a system, the need for the business processes conducted by the organisation to be represented, the need for organisational data to be captured and stored – which will remain for the foreseeable future and unless organisations change from their current form to be unrecognisable. As such, their representation in software will always be amenable to an architectural treatment much like as today. Secondly, most organisations lack embedded software expertise sufficient to meet their own recognised software needs so that software development will, typically, always be outsourced to specialist development organisations. As the primary or driving need exists within the organisation, there is no alternative to accessing the stakeholder within the commissioning organisation for understanding their needs to develop the software intensive solution. As such, the need to capture and process requirements between organisations will always be necessary. One happy conclusion is that the relationship between requirements and architectures is here to stay, and that the work of this book and that like it will grow in relevance! Acknowledgments The first author wishes to thank Lucia Rapanotti for her careful reading and detailed critique of this chapter.

1 Introduction: Relating Requirements and Architectures

9

References 1. Ferreira S, Collofello J, Shunk D, Mackulak G (2009) Understanding the effects of requirements volatility in software engineering by using analytical modeling and software process simulation. J Syst Softw 82(10):1568–1577, SI: YAU 2. Schaller R (1997) Moore’s law: past, present and future. IEEE Spectrum 34(6):52–59 3. Tootill G (1998) The original original program. Resurrection: the computer conservation society, no. 20. ISSN 0958–7403 4. Enticknap N (1998) Computing’s golden jubilee. Resurrection: the computer conservation society, no. 20. ISSN 0958–7403 5. Perry DE, Wolf AL (1992) Foundations for the study of software architecture. ACM SIGSOFT Software Eng Notes 17(4):40–52 6. Shaw M, Garlan D (1996) Software architecture: perspectives on an emerging discipline. Prentice Hall, Englewood Cliffs 7. Bass L, Clements P, Kazman R (2003) Software architecture in practice, 2nd edn. AddisonWesley Longman, Boston 8. Royce W (1970) Managing the development of large software systems. Proc IEEE WESCON 26:1–9 9. Cheng B, Atlee J (2007) Research directions in requirements engineering. In: Proceedings of FoSE 2007: future of software engineering. Washington, DC, pp 285–303 10. Bird P (1994) LEO: the first business computer. Hasler, Workingham 11. Grant RM (2003) Cases in contemporary strategy analysis. Blackwell, USA/UK/Australia/ Germany. ISBN 1405111801 12. Turski WM (1986) And no philosophers’ stone, either. Information processing 86:1077–1080 13. McManus J, Wood-Harper T (2008) A study in project failure. Tech rep, Chartered Institute of IT. Last accessed 27 March 2011