Can architecture descriptions help prospective users to visualise the solution in terms of meeting its requirements? Peter Henderson Open Middleware Infrastructure Institute Electronics and Computer Science University of Southampton September 2007

September, 2007Peter Henderson, University of Southampton2 Abstract Defining requirements is a complex matter. Without realising it, we often end up describing something that is too hard to visualise and may well be undeliverable. Business leaders and their analysts regularly define IT requirements that are not achievable. It is as if, in engineering terms, they are requesting a 1000 metre cantilever bridge, which is way beyond current capabilities. It is not so easy to visualise software architecture, so the impossible is not so obvious. This session will discuss the importance of linking requirements to architecture and using the architecture to focus on the customer's real business needs. The group discussion will focus on approaches to effectively capture and manage requirements. This will be achieved by drawing on a realistic solution, a "roving autonomous vehicle" capable of being used on a Mars landing. The proposed solution will be required to focus on open systems, due to the nature of how the solution will be delivered from a consortium of independent vendors, to re-use available assets and for the ability for it to be upgradeable throughout its life.

September, 2007Peter Henderson, University of Southampton3 Architecture and Requirements What is the relationship between architecture [description] and requirements gathering? Can we use architecture descriptions to better help prospective users visualise our solution? How do top-level requirements induce lower- level requirements in a loosely-coupled modular architecture? Are there architecture lessons from Open Systems/Open Source that need to be applied more broadly?

September, 2007Peter Henderson, University of Southampton4 Modularity, Upgradeability, Openness Take it as given that large, complex systems will be modular And that one of the main requirements will be upgradeability to meet evolving business requirements Which in turn leads to an arguable requirement for openness in the architecture, enabling independent suppliers to contribute value-adding components.

September, 2007Peter Henderson, University of Southampton5 Motivating Example This is a Roving Autonomous Vehicle. It accepts instructions in the form of a plan, which it then carries out autonomously. It is a fictional example.

September, 2007Peter Henderson, University of Southampton6 Structural Architecture of RAV1.0 The Manager module is in charge. It instructs the Power module when movement is required. It instructs the Drive module when steering is required. It uses information from Sensor 1 to avoid collisions. It uses information from Sensor 2 to determine its own location. It uses the Comms module to communicate with home. Sensor 1Power CommsManager Sensor 2Drive This is Version 1.0. The RAV has been developed through many versions, separating autonomy from more advanced functionality and opening the system to competitive supply of components.

September, 2007Peter Henderson, University of Southampton7 A note on Notation Using a shorthand for UML component diagrams The arrows can be read as “uses” Or as interfaces, supplied by one component to another Or as a place to address functional requirements Components may be hardware, software or a combination of both Components are potentially independently procurable CommsManager CommsManager

September, 2007Peter Henderson, University of Southampton8 Supply of RAV1.0 There are 7 components here. The six modules and the platform As well as supplying the physical solutions (wheels, etc), the platform also provides the on-board networking and other infrastructural aspects. Each of the 7 components is potentially separately procurable. Colour here denotes supplier. Each component contains both hardware and software. Sensor 1Power CommsManager Sensor 2Drive

September, 2007Peter Henderson, University of Southampton9 Mapping Requirements onto Architecture Requirement on RAV –The RAV will accept an instruction to move to a new location Induced Requirement on Comms module –The Comms module will store received messages until they are requested Induced Requirement on Manager Module –… etc. Induced Requirement on Infrastructure –… etc. Sensor 1Power CommsManager Sensor 2Drive

September, 2007Peter Henderson, University of Southampton10 Open Systems What does it mean for a system like this to be Open? –A specified Architecture –Specified Interfaces within the Architecture –A responsible Standards Body/Design Authority for those specifications –A Conformance Body? –Planning for evolution of requirements that meet perceived business needs Sensor 1Power CommsManager Sensor 2Drive

September, 2007Peter Henderson, University of Southampton11 Related Issues Must meet both functional and non-functional requirements, where the latter are either qualities or constaints. As architects, we need to make trade-offs. Can we draw a parallel between COTS packages and bespoke systems, where we need Architecture+Open Systems+Re-usable assets to achieve an equivalent level of early visualisation?

September, 2007Peter Henderson, University of Southampton12 Discussion Sensor 1Power CommsManager Sensor 2Drive What is the relationship between architecture [description] and requirements gathering? Can we use architecture descriptions to better help prospective users visualise our solution? How do top-level requirements induce lower-level requirements in a loosely- coupled modular architecture? Are there architecture lessons from Open Systems/Open Source that need to be applied more broadly?