On 4 October, I participated to an event in honour of Axel van Lamsweerde, my former PhD supervisor, who turned emeritus this fall. The event had an impressive list of speakers and generated many interesting discussions in and around the warm auditorium SUD11, a lecture room I have spent hours in as a student years ago.
I talked about the value of requirements uncertainty. I made the point that uncertainty is inevitable in requirements and architecture decisions and we should therefore embrace uncertainty instead of ignoring it. I argued that our past focus on precise specification is misguided when requirements are uncertain and called for a goal-based scientific approach to software decisions under uncertainty. Important and fascinating research lies ahead of us.
The slides are on my new slideshare account and here:
Last week, the BCS Requirements Engineering Specialist Group organised a workshop on “Agile Development – A curse or a blessing for requirements engineers?”. This was held in a fully packed room at the BCS headquarter in London. By coincidence, there was another talk an agile organised by the BCS Central London branch in the very next room, so discussions in the hall were all buzzing about agile and some people weren’t quite sure which room to go to. The demand for information about agile keeps growing. This is probably due to the growing pressure to ditch large-scale projects with rigid contracts in favour of smaller-scale agile projects notably for Government IT projects, but also to the still widespread misunderstanding and misuse of agile methods, the difficulty of sorting out facts from hype in many agile presentations, and a legitimate concern of requirements engineers and business analysts about the impacts that such methods would have on their work.
The event kicked-off with a talk by Keith Braithwaite who described how requirements are discovered in agile projects through user stories and acceptance tests with a greater emphasis on conversations and less on documentation. But what makes a good user story? To be accepted for implementation, user stories have to satisfy the INVEST criteria; they must be Independent, Negotiable, Estimable, Small and Testable. To discover and organise user stories, one typically starts from larger “epic” and organise them in story maps that provides an end-to-end description the users’ tasks and goals. Keith explained he first discovered the benefits of test-driven development that is central to agile development many years ago while working on system to optimise the placement of GSM antenna for which he was developing UML models and Z specifications. He used this system as example to illustrate the technique of story mapping. He contrasted this form of “low resolution model” –a phrase that I liked– to the more detailed UML activity diagrams or BPMN models one could also write for such models.
There were lots of discussions during and after the talk questioning some of the assumptions behind agile methods. As usual, it is impossible to go to the bottom of things in one short evening, but I found the event interesting in teasing out different sensibilities on this topic, from the young enthusiasts to the veterans who’ve seen it all before.
One thing that wasn’t discussed so much during the evening is the impact that these changes have on the work practices of requirements engineers. This is something I’d like to come back to at some point. In the meantime, I would recommend the research done by Angela Martin, Robert Biddle and James Noble described in their paper “An Ideal Customer: A Grounded Theory of Requirements Elicitation, Communication and Acceptance on Agile Projects”. It describes the many roles requirements engineers play in agile projects (geek interpreter, technical liaison, negotiator, diplomat, customer coach, super-secretary, etc.) and the difficulties they face in fulfilling these roles, notably in sustaining the pace of having to deliver quality user stories at regular interval while keeping constantly engaged with both developers and large numbers of stakeholders in the client organisation. It also describes some of the practices that have emerged to try overcome to these difficulties, for example by having iterations where programmers work on technical tasks (e.g. repaying technical debt and setting up support tools) so that it gives customers time to think ahead, organising customers boot camps on agile processes, and having programmers work as apprentices in the customer’s organisation. These are probably not enough to fully resolve the workload problem for requirements engineers and customers, but they can somewhat lower their impacts.