Book Image

Managing Software Requirements the Agile Way

By : Fred Heath
Book Image

Managing Software Requirements the Agile Way

By: Fred Heath

Overview of this book

Difficulty in accurately capturing and managing requirements is the most common cause of software project failure. Learning how to analyze and model requirements and produce specifications that are connected to working code is the single most fundamental step that you can take toward project success. This book focuses on a delineated and structured methodology that will help you analyze requirements and write comprehensive, verifiable specifications. You'll start by learning about the different entities in the requirements domain and how to discover them based on customer input. You’ll then explore tried-and-tested methods such as impact mapping and behavior-driven development (BDD), along with new techniques such as D3 and feature-first development. This book takes you through the process of modeling customer requirements as impact maps and writing them as executable specifications. You’ll also understand how to organize and prioritize project tasks using Agile frameworks, such as Kanban and Scrum, and verify specifications against the delivered code. Finally, you'll see how to start implementing the requirements management methodology in a real-life scenario. By the end of this book, you'll be able to model and manage requirements to create executable specifications that will help you deliver successful software projects.
Table of Contents (12 chapters)

Actualizing just-in-time development

When people are first introduced to a feature-only backlog, they tend to ask questions like, But what about research tasks or spikes (product testing tasks in order to explore alternative solutions)?, What about generic tasks like applying style sheets?, or We need a separate task for setting up a Continuous Integration pipeline. The response to all these concerns is always the same:

Tasks do not exist in a bubble. We are only doing things that help to implement a feature. If a task doesn't contribute toward a feature, then we should not be working on it.

As discussed in Chapter 3, Writing Fantastic Features with the Gherkin Language, features can reflect both functional and non-functional aspects of a functionality. So, that research you want to do into different indexing engines is almost certainly tied to a search-related feature somewhere in your backlog. If you start working on this task, it means you start working on that feature...