The importance of requirements management (RM) in software development need not be further emphasized. Based on both research data and empirical evidence, it has become a cliché to point out that adequately capturing what is expected of developers (what problem their end product should be able to resolve, and how exactly it should do that) is the single most important factor that could make or break the success of the entire software project.
In fact, requirements are at the very root of the transition process that is considered by some as revolutionary to the way we develop software. This evolutionary process gave rise to Agile, and thus requirements can be seen as the main driving force behind Agile’s growing adoption and popularity.
The primary objective of Agile, this fairly modern set of principles, concepts and frameworks, is to provide a way for development teams and companies to better serve the needs of their customers. Above all, the aim of any Agile development project is to deliver working software as fast as possible, where “working” actually means a product that is able to successfully resolve the customer’s problems. In order to be able to deliver a solution, one must first understand what the problem is. That’s why requirements management is (or at least should be) at the heart of any Agile project.
How does RM become Agile?
Somewhat confusingly, however, there is no such thing as “Agile requirements management”. There is no agreed-upon definition, or set of processes that you could simply implement, allowing you to claim to be Agile in your requirements management. There are countless best practices, tools, processes, and concepts used to enhance the quality and clarity of requirements in an Agile environment.
Pro tip: Sign up for our free Agile Training Course for Agile insights & best practices!
This of course stems from the very substance of Agile, which says that you should favour communication, collaboration, flexibility and working software over tools, processes or documents set in stone. Basically, being Agile means that you should use whatever works best for you. While highly inspiring, this thought doesn’t help you much in going about implementing Agile requirements management. In the following section, we’ll list some of the most useful requirements management tips from Agile practitioners around the world:
Agile Requirements Management Lifecycle
Most practitioners advise that an initial requirements envisioning phase is fundamental in your requirements management lifecycle. At this stage, you’re not trying to get down to the details of how your end product will work. Instead, you will just aim to identify your project’s scope, which will help you to understand and estimate the cost and time needs of the project. A high-level understanding of business goals, and an outline of what’s needed is what you’re aiming for here.
Once the project’s high-level goals, schedule and costs have been agreed on, it’s time to really get the Agile requirements management lifecycle rolling:
1) Creating the requirements backlog
First, you’ll be creating a requirements backlog. This is where it’s a good idea for us to introduce perhaps the most important and useful of Agile RM concepts: user stories. User stories are short, informal descriptions of an everyday use case – basically, one or a few sentences in plain, everyday or business language describing how the user expects the software to work in a certain scenario. The general template for user stories use is the following: “As a <role>, I want <goal/desire> so that <benefit>”. Your requirements backlog could include visual models or UML diagrams, functional requirements, user stories, etc.
2) Requirements planning and prioritization
The next stage of the process aims to evaluate requirements based on business strategy and objectives, and to define what needs to be built. Requirements (user stories, functional requirements, etc) will be prioritized based on their importance, effort needs, etc.
3) Decomposition, grooming, creating the product backlog
The resulting set of general requirements will go through decomposition and some “grooming” before making their way to the product backlog. Essentially, this stage of the process helps you refine requirements and “translate” them into actual features (directions that your developers will understand). Including your development team in the process helps make sure that all the requirements are clear and easily understood by the team that will implement them. It’s important that user stories are linked to features and tasks, so that developers don’t only understand what their task is, but why they are doing what they’re doing.
From the product backlog, tasks and features are distributed into release backlogs, which are then further broken down into release backlogs, sprint backlogs, and actual tasks.
Last but not least, it’s immensely important to mention the necessity of customer interaction. By including your customers in the entire process of capturing and refining requirements (rather than showing them at certain points what you’ve accomplished on your own), you can make sure that the project is not derailed by a fundamental misunderstanding of goals.
Naturally, the above tips and practices are barely scratching the surface of the vast topic of Agile requirements management. To learn more, sign up for our Agile Training Course, or try the requirements management tool used by global leaders such as Daimler, Medtronic, Samsung, and others.