Can architecture descriptions help prospective users to visualise the

solution in terms of meeting its requirements?

Peter HendersonOpen Middleware Infrastructure Institute

Electronics and Computer ScienceUniversity of Southampton

September 2007

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

September, 2007 Peter Henderson, University of Southampton 3

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, 2007 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.

September, 2007 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.

September, 2007 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.

September, 2007 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

September, 2007 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

September, 2007 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

September, 2007 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

September, 2007 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?

September, 2007 Peter Henderson, University of Southampton 12

Discussion

Sensor 1 Power

Comms Manager

Sensor 2 Drive

• 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?