I just finished reading “Requirements Definition & Management for Dummies” by Robert D. Schneider, Tony Higgins and Keith Barrett. The eBook is being freely distributed by Blueprint Software Systems (registration required). While it’s intended to draw attention to Blueprint’s requirements management software, it’s not just marketing literature. The book makes some good points.
Much of the material is centered on the role of business analysts in software development. I know some will argue that agile projects don’t need business analysts. I agree — on small projects. I disagree on enterprise-scale projects. Big, complex undertakings need high-level analysis and design and it has to be done in an agile way. Blueprint gets it.
Here are a few excerpts that got my attention:
From Chapter 1: Meeting the Business Analyst
“In many ways the role of a business analyst parallels that of an author writing a story or screenplay — either way, you could call it “The Voyages of the Enterprise.” Indeed, the business analyst must tell the story of the application that the business needs and do so in such a way that the business stakeholders can easily consume the story and confirm that it meets their needs, and that the technology stakeholders (that is, testers, architects, and developers) can read it and understand what they need to test, design, and develop. As with any good story, the business analyst must use appropriate language, add in clear illustrations, and provide good visual imagery.”
I love the story analogy. Business teams don’t want to read technical documentation. They don’t understand all the acronyms and they don’t care. Conversely, technical teams thrive on technical details. Someone has to bridge the gap.
From Chapter 2: Conquering the Challenges of Business Analysis
“The challenges business analysts face are even more formidable because their daily responsibilities are in continual flux and undergoing ceaseless transformations. Why? … end-users take advantage of only 45 percent of delivered features (according to the Standish Chaos Report), and rework consumes 40–50 percent of project budgets (Boehm and Basili). Issues that the project team could have addressed when defining requirements are key contributors to these unfortunate numbers. In fact, faulty requirements form the root cause for 75–85 percent of rework (Leffingwell).”
“Good requirements and agile (development) are absolutely compatible … These requirements are detailed for each iteration individually to a level consistent with other methods just before implementation.”
This approach mimics the way agile teams write epics and decompose them into stories just in time for the target sprint. That’s an approach that benefits every software development team.
From Chapter 3: Building a Better Business Analysis Experience
“Three major (yet surprisingly simple to follow) strategies make the job of creating software requirements easier:
* Getting visual
* Getting social
* Getting going”
Blueprint advocates using diagrams, charts and graphs not just words, sentences and paragraphs. Visual representations are more likely to be understood and remembered. They also advocate frequent interactions and exchanges among team members. It’s not simply a matter of point-to-point communications, information has to be shared and accessible to everyone on the team.
While I’ve never used the Blueprint software and thus cannot recommend it, I can recommend the book as worthwhile reading. It’s concise and easy to follow.