Requirements management in Agile projects

It has long been known that properly gathered and tested customer requirements are the key to sound engineering decisions and commitments that can actually be met. Yet many projects still fail precisely because of chaos in their requirements. This is true both of projects run on heavyweight formal methodologies and of projects delivered with lightweight approaches.

Why does this happen? With “heavyweight formal” approaches, the team most often loses control over a large number of low-level requirements amid a high rate of change and forgets about analysis, traceability, coverage testing, etc. It slips into “fix on the spot” mode, moving the code further and further away from the original requirements and relying on modern engineering practices. As a result, products whose upfront analysis and design cost considerable sums lose all the benefits that “heavyweight” methodologies offer and become a heavy lift to evolve and maintain.

With lightweight approaches, requirements stay at a very general level, without detail, and quite rightly so, by the way. Requirements management is exposed to very high risks, and managing them is quite costly and, as experience with heavyweight approaches shows, not always effective. This is all the more true because the concept at the core of lightweight approaches, validating product ideas by building the product (A/B testing or split testing), pushes developers to work directly at the level of behavior scenarios. That opens up the prospect of the resulting code losing its maintainability and growing more expensive to change as it degrades under a mass of mistakes, big and small, and the compromise and dead-end decisions reached through trial and error. Relatively young products lose momentum and need serious rework.

It stands to reason that what’s needed is a synthesis of practices from lightweight and heavyweight methodologies. It should keep all the advantages of upfront requirements analysis and the translation of requirements into the product architecture, as well as those of lightweight incremental and iterative approaches, which make you more responsive to what the business wants.

That’s what we’ll be talking about. I’d like to invite you to learn about and try out practices for analyzing, testing, and managing requirements that have been proven on large projects in both custom software development and product development. These practices let you effectively analyze and test requirements, manage changes to requirements, and assess and prevent project risks without sliding into heavyweight formal approaches.

You’ll get the distilled essence of approaches that have evolved over the past five years. We’ll start, of course, with requirements management theory, with particular attention to the economic case for various practices across different products and teams. But the main focus is practical application. We’ll take real tasks and gather, analyze, and test their requirements, managing risks along the way, and at the end we’ll see how much easier it becomes to move on to behavior scenarios and architecture. We’ll also discuss how the practices we present affect the rest of the project’s life. And we’ll be sure to discuss their drawbacks and possible directions for developing them further.

At the end of the training, you’ll receive individual homework assignments to reinforce your skills, and I’m happy to discuss and review them with you online afterward.