This month's sugsa was a cross-talk from the Business Analysis community.
Mohamed described an iterative process as just multiple quick failures (wagile, thanks Karen), if we decide to skimp on requirements. His stat was that 70% of defects are injected during the requirements phase. After gathering, the challenge becomes requirements management and communication. This communication is difficult because the audience is broad and diverse.
Requirements communication should have a few characteristics.
- connect: we need collaboration and traceability
- actionable: when is it done? get commitment (intention ≠ commitment)
- units: time & money
Communication is not just representation.
Interesting (and new) fact to me is the existence of the Business Analysis Body of Knowledge (BABOK). Although the $30 pdf ($60 for print) price has put it onto my library backlog, and not too near the top.
Peter Hundermark probed a bit on whether traceability was really important.
To me, as a developer, traceability had always meant the lengthy and painful process at the end of waterfall where we point to screens an show where each feature can be found.
Mohamad extended this backwards to linking requirements to stakeholders and the origin of the item, so that we can get feedback on the intention when required. "Where it came from and where it went". Which is actually quite appealing.
Marius de Beer was looking for the "smells" or indicators that BA has gone bad.
Requirements that are not quick to apprehend are smelly. They should be easy to interpret upfront. In that context, 90% of requirements are not clear. As an example, when we talk about oranges, you should get a vivid picture of an orange in your head.
Asking context free questions is a technique to probe further while attempting to listen with a solution in mind.
The difference between regular analysts and BBND analysts (Mohamad's employer) is that they are 100% responsible for delivery.