Questions for discussion

IBM Confidential © 2003 IBM Corporation

Requirements to Architecture

© 2006 IBM Corporation2 IBM Confidential

Questions for discussion

Can architect descriptions help prospective users to visualise the solution in terms of meeting its requirements

What is the relationship between architecture and requirements

Can we used architecture to describe to help prospective users to visualise our solution

How do top level reqs. Induce lower level reqs. In a loosely coupled architecture

Are there architecture lessons from Open Systems / Open Source that need to be applied more broadly?



Supply Chain of Requirements

Initial creator created then hands over Next person splits that problem out to say

multiple suppliers Each supplier will interpret those requirements

differently and provide possible alternative solutions to break down the problem

The issue is that we never loop back to validate the new requirements that are evolving versus the original requirements set



What is a system – the following are some of the terms we felt were included in the scope of a system

Hardware Software People Procurement Business Suppliers



Captured discussion points Two aspects to requirements

– Functional & Non-Functional– Need to use both of these to work out what is technically feasible– ISO standards now say there is only functional requirements:

some of which are quality requirements. E.g. Security, Availability ISO 9010, ISO 90126, Robert Grady

We need to take a broader view than Users this should be multiple stakeholders– E.g. call centre, the person at the end of the phone, etc– The people who want the solution are not IT people or IT literate

(we want solutions described in business terms)

No requirement is completely independent of the architecture that is chosen– No requirement is made that was not perceived by the possible

architecture



Captured discussion points

Makes much more sense to look at things structurally as you can point at things. Rather than behaviourally e.g. Use Cases

– You need both. Health system Example but in different measures

Architecture is important when you want to describe the requirements

– COTS are generally more successful as they refine the scope through the product

Two beliefs1. Build requirements then architecture2. Build them with the architecture – the challenge is having the right

understanding of known tradeoffs, etc to make as you go along



Captured discussion points Handbook of architectures

– This could help procurers to understand the art of the possible– It will require a competence that could describe these architectures in a

business language

What do we mean by a failed project– Example here is a system that team makes a solution work in the end– Due to the original requirements are changed– Proposition is that the requirement review is missed due to the supply

chain

What do we mean by deployment– At initial stages the solution does not meet the initial requirements– The requirements evolve and the system does meet the end goal

requirements

This is made harder due to the public sector procurement rules in that



Captured issues Common challenge is that the people paying for the solution

have different visualisation of requirement to the people building the solution

Arrows work at less technically aware people. UML relationships are formal methods. (visualisation)

If you go in with a set of architectures / requirements you may still get to a point that you do not have a solution you actually want “A little knowledge is a dangerous thing”– I don’t need a roving land vehilcle I require a telescope

When you have something that is tangible, air traffic control, etc it is much easier to assume that an Architecture is useful if its something that is fuzzy such as a data mining solution, it is not as useful as you can constrain the design



Captured Issues

To what level should the architecture be exposed to the client– Implicit understanding from requirements folk that clients

understand architectures– Too much understanding of architecture will destroy innovation

Need to distinguish the architecture of a problem from the architecture of the solution– Should be able to articulate the problem first

Specifying the architecture can constrain innovation Issue is not lets write another book, lets get our clients

to read the books that have already been written



Open Systems / Source

Issue is of trust– If you only have interfaces you do not get the total trust– This can be gained through standards bodies

Can we build a bespoke solution using off the shelf bits but with the assumption that they will have to change their business / initial requirements– This has to be in a constrained domain like SAP, internet retailer, – It would be good to capture a Domain taxonomy / classes of system

• E.g. Internet retail system• ERP• EAM• CRM• Resource management• Payment Systems• Credit checking systems• Financials systems (ledgers , accounts payable, receivable)• Systems to meet regulation – the more regulation you have & the more complexity you have.

– This could go up to the generic domain such as data management systems, transaction systems



Next Steps

A number of possible next steps were discussed:– A conference to share case studies– A practical guidance handbook for understanding requirements– Sharing of ISO standards around requirements language

A conference for many clients on the subject of architecture to requirements– Pull together case studies / architectures– Invites include CTOs CIO Chief Architects across the industry– Starter set to include Grady

Practical guidance handbook for “So you are having an IT System” Sharing of ISO standards for definition of functional requirements to be

shared



Categories of requirements

Two aspects to requirements– Functional & Non-Functional

– Need to use both of these to work out what is technically feasible

– ISO standards now say there is only functional requirements: some of which are quality requirements. E.g. Security, Availability ISO 9010

Business rules & time critical rules that you cannot break– But this still determines your architecture



Shopping book is a good idea, but we are along long away from that

If we cannot define standard architectures in a language can we describe standard questions– Architectural decisions & patterns could help here



ACTIONS

Liping Zhao to send everyone the ISO standard of requirements labelling

Peter Eeles to send ISO 90126, Robert Grady material



What type of requirements

Person who will get the machine– Accept instruction to move to a new location is not

something I would like

– But as an assembler we need to know that these things will work together.

Documents

Questions for discussion