Agile Software Requirements
Software requirements always seems to generate debate on the best way to collate the requirements – both functional and non-functional. In many ways, the word “requirements” draws on the legacy of a waterfall approach that generated large wades of documentation, with little though to the needs of the development team – no need to go on down this road. Personally, I prefer the word “application behaviour” for obvious reasons – BDD.
Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise is therefore an interesting book in many ways, since you’d expect an agile requirement book to be re-iterating well documented concepts around story writing, backlogs and acceptance criteria/tests, coupled with development practices to validate the application has delivered on the required behaviour. My expectation of the value of the book was there not high at the outset because there are already many good books out there that deal with stories etc. I’m also conscious that Dean Leffingwell worked at Rational Software, were RUP was conceived, and therefore expected a SAFe push from the book, even though the title doesn’t state SAFe. SAFe maybe fine if you are running a 300+ person project, but for many companies this isn’t going to be the case.
Having taken time to read the book, from my viewpoint, there are only a few useful sections:
- Chapter 12 – Requirements Discovery Toolkit. This chapter offers some direction around running workshops, interviews and questionnaires. There’s also the usual mention of User Experience (UX) mock-ups that we should all be familiar with these days. Competitive analysis is also touch on – something few banks often do, but one in particular that I was involved with, did well, and benefited from the direction they took their electronic trading product.
- Chapter 18 – Requirements Analysis Toolkit. This lists a number of methods (e.g. activity diagrams) which I would hope most would be aware of.
- Appendix D – Backlog Meta-Model. Possibly the most useful page in the book, unless you’ve built your own already. Interestingly, its available online (and thus possibly removing the need for any agile minded individual to buy the book).
In summary, the book is probably useful for anyone who wants a refresher on requirements, or hasn’t embraced user story mapping, backlogs, BDD and other agile techniques. Finally, if you are on the SAFe road, its probably a must read.