My thanks for an interesting few hours at the BCS "Requirements for Changes to Existing Systems" event last Thursday.

The discussion sparked off quite a few thoughts and it was interesting to hear comments and views from a forum well represented by 'Suppliers' especially as I tend to sit on the 'acquisition' side of software intensive systems (in the whole ship domain).

Even though we have a tendency to a 'green-field' view the context and concept-of-operations soon constrains solutions and by the time we start manufacture (build) we are well into the brown-field scenario with changes and this only increases with changes needed through life to maintain/improve capability of the product. With this scenario Ian's ideas rapidly fell on to fertile ground !!!

As to the open forum I was particularly interested in the ideas around:

• " … the need to raise the game above the requirement to be professional … " (this came up against 'self documenting' as well as 'professional bargain vs. commercial pressures' and how this might be expressed in contract as well as partnering terms.
• " … agile techniques vs. contracting against requirements … " and how this would shift the current contracting-to-meet-requirements paradigm.
• " … model and diagrammatic techniques to elicit needs > requirements … " and the subsequent tool driven links into functional specs and design/test and acceptance.
• " … the Apple approach identified as starting with the User documentation first … "
• " … how the Acquisition Community could over come the Supplier's 'pay-money- trust-me-it-will-be-alright-on-the-night' / big-bang approach through effective monitoring / reporting and encouragement of 'good behaviours' (on both sides) … "

Generally how can Customers be really good acquirers and effectively participate in the transition from need to fielded product.

My thanks again for an interesting session.

Ten tips kindly forwarded by Phil Cantor (Misys) following the event:

1. State with each requirement how likely it is to change
2. Try to find “economic capacity” (dosh) to allow code/design creation to include non-functional requirements demanding self-documentation or other things so those enhancing it in the future can understand it
3. “Goals” are handles that amplify requirements, helping people make changes in the future
4. Distinguish in the requirements between the technical system and the work system
5. Consider more use of prototypes/mockups to elicit better requirements and gain better buy in
6. Keep the level of detail of requirements statements appropriate to the level of abstraction, eg is a CRUD operation really four separate use cases (create, read, update, delete)?
7. If satisfying the requirement is more complex than it seems to the sponsor, be sure to expose the complexity to keep expectations at a helpful level
8. Use a dictionary to disambiguate terms that can otherwise be openended or vague requirements, eg “must work with common browsers”
9. There are two consumers of requirements: (a) the poor sods to have to build the solution and (b) the poor sods who then have to use it! Good principle for users and builders to work from the same base artefact(s)
10. Requirements can have terms defined well by use of XML schemata

Thanks, Phil!

Hi

Also 2 other good points mentioned where:

1. Trade-offs agreed between the Business & IT i.e. compromises;
2. Things highlighted for testing e.g. things that could be missed or complexities.

Is it possible to attach the original PowerPoint presentation for context / reminder?

Hassan, yes, I have published my slides at

http://easyweb.easynet.co.uk/~iany/consultancy/brownfield_re.pdf

Hope you find them helpful.

Ian