© 2003 ibm corporation ibm confidential. requirements to architecture © 2006 ibm corporation 2ibm...
Post on 18-Dec-2015
218 views
TRANSCRIPT
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?
Requirements to Architecture
© 2006 IBM Corporation3 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation4 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation5 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation6 IBM Confidential
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 beliefs
1. Build requirements then architecture
2. Build them with the architecture – the challenge is having the right understanding of known tradeoffs, etc to make as you go along
Requirements to Architecture
© 2006 IBM Corporation7 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation8 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation9 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation10 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation11 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation12 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation13 IBM Confidential
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
Requirements to Architecture
© 2006 IBM Corporation14 IBM Confidential
ACTIONS
Liping Zhao to send everyone the ISO standard of requirements labelling
Peter Eeles to send ISO 90126, Robert Grady material
Requirements to Architecture
© 2006 IBM Corporation15 IBM Confidential
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.