Peter Henderson Open Middleware Infrastructure Institute Electronics and Computer Science

1. 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

2. 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. Peter Henderson, University of Southampton

3. Architecture and Requirements • What is therelationship 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? Peter Henderson, University of Southampton

4. 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. Peter Henderson, University of Southampton

5. 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. Peter Henderson, University of Southampton

6. 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 1 Power Comms Manager Sensor 2 Drive 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. Peter Henderson, University of Southampton

7. 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 Comms Manager Comms Manager Peter Henderson, University of Southampton

8. 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 1 Power Comms Manager Sensor 2 Drive Peter Henderson, University of Southampton

9. 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 1 Power Comms Manager Sensor 2 Drive Peter Henderson, University of Southampton

10. 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 1 Power Comms Manager Sensor 2 Drive Peter Henderson, University of Southampton

11. 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? Peter Henderson, University of Southampton

12. Discussion • 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? Sensor 1 Power Comms Manager Sensor 2 Drive Peter Henderson, University of Southampton