Requirements management, SOA and Simulation - 2nd in a series
by
Charlie Bess
Requirements management is an area that has had significant technological investment in the past few years. Most of that activity has been related to formal documentation and change management, codified in tools like CaliberRM and Requisite Pro. In preparing for a client presentation about the state of requirements management last year, I came across an interesting article:
Heumann, Jim, The Five Levels of Requirements Management Maturity,
The Rational Edge, February 2003
That described a maturity progression related to requirements management:
- Level 0 - No Written Requirements
- Level 1 - Written Requirements
- Level 2 - Organize Requirements: Format, Secured, Store, Versioning
- Level 3 - Structure Requirements: Identify "Types" of Requirements
- Level 4 - Trace Requirements: Track, Prioritize Relationships
- Level 5 - Integrating Requirements: Coordinate with other software tools in the software life cycle
This works well when the user knows what they want and are willing to commit to those requirements. Agile development techniques can be brought to bear to help the client converge on a set of requirement techniques. A diverging set of requirements never happens in development – right??
But what affect does Service Oriented Architectures (SOA) and model driven development have on the state of requirements management. It seems the current requirements management tools need to be supplemented by a whole other set of techniques. Just like when CAD software was available to do stress analysis on bridges and other physical structure, estimation and simulation techniques for SOA are needed to optimize and sometimes understand production performance.
Although SOA has received a great deal of press recently, the implications on the behavior of the enterprise from a governance and requirements management perspective seem to be overlooked.
By definition, most of the work done in a SOA will be built upon existing services within the enterprise or providers to the enterprise. Those services will already have users that place a load on the service. They also have contracts, expectations or Service Level Agreements.
Adding new load will require the addition of simulation techniques to the requirements process, to ensure that the new application does not bring the whole enterprise down like a house of cards. Just because a service can fulfill a need, does not mean it should. Simulation techniques will help identify if new services will be required to meet the specific needs of the application or a leveraged service is sufficient.
As SOA techniques and Utility Computing techniques align, simulation expectations will need to reach whole new levels of maturity (not to mention the monitoring needs of the services).
