Notes:
Well the first new area I got involved in was “requirements capture”. This is a key part of building bespoke software – but, on one project, the process had stalled. No forward progress had been made for weeks.
What I found was illustrative of a problem of growth: the business analysts and the customer were designing application screens. On a small, tightly knit project, this needn't be a problem, but on a large complex project it means that they are swamped with detail and lose sight of the objectives.
This manifested itself as previously agreed “screeens” being reworked as the interactions with other functions were recognised. When I got involved the whole effort was devoted to propaging waves of these changes through the system “requirements” and no new screens were being designed.
In the face of dogged resistance from the customer's project manager I changed the regime. (He was determined to ensure that every screen could be navigated with the minimum number of key presses.)
By documenting the relationships between the principle activities of the customer's operation and writing stories about how the staff and computer system co-operated for each activity we established a consensus about what each “screen” was for.
The screens became simpler: no more going back to “add buttons for X, Y and Z”. And the interactions between screens were understood and controlled.
The BA's still had problems designing GUI screens. But as the stories were documenting what the screens needed to achieve they were able to work with the designers and developers to decide how the screens could function.