Swiss Requirements Day
Gilbert Wittwer, Amstein + Walthert Progress AG, Teamleader IT-Consulting
*Does requirements gathering have an impact on design decisions?
What constraints can a business analyst set unwittingly?*
Business analysts‘ golden rule: Separate requirements (what) from design (how) decisions!
Common requirements gathering is done with
– Use cases (UML). UML, though, has object-orientation in mind in order to allow for automatic generation of classes
– User stories (XP, Agile) is based on natural speech, i.e. it is technology-free. Properties inclunde INVEST (independant, negotiable, valuable, estimable, small, testable) and SMART (specific, measurable, agreed-upon, realistic ,time-boxed)
But also natural speech can structure things, i.e. technology free formulation doesn’t mean that things are design free.
The New Technolgies‘ Promise around
CORBA, EAI, SOA, SaaS, Cloud Computing, ITIL, IT-Governance
Promises: Unlimited flexibility and adaptibility to business needs. Manageability of ICT can be improved.
As a consequence rew requirements should be approached flexibly and open mindedly.
What constraints can a bssiness analyst set unwittingly?
– omission of key performance factors (non-functional requirements)
– assumed availability of basic functionality (e.g. existing user right administration)
Consequneces are limitation of flexibiltiy, adaptability, scalability, extensibility.
Road work planning
In the first case the description was too restrictive, it showed an incomplete view of the business cases.
Problems can stem from
– incomplete view of business needs: Validity period of data omitted (probably assumed available)
How to avoid implicit setting of constraints?
– Awareness of implicit design decisions
– Explicit settin of design constraints when unavoidable, in accordance with strategical and tactical goals, potential integration of business needs,
– choice of words: Two terms, one thing Realtion between postcode and
Explicit setting of constraints requires: Analysis of limitations, possibilities: Is a solution good enough, how can it be adapted later?
Validation of design decisions through busienss requirement analysis, involving stakeholders.