- 1. Requirements Management
- 1 What is Requirements Management?
- 2 Why do you need Requirements Management?
- 3 Four Fundamentals of Requirements Management
- 4 Adopting an Agile Approach to Requirements Management
- 5 Conquering the 5 Biggest Challenges of Requirements Management
- 6 Three Reasons You Need a Requirements Management Solution
- 2. Writing Requirements
- 1 Functional requirements examples and templates
- 2 Product requirements document template and examples
- 3 How to write system requirement specification (SRS) documents
- 4 Jama Software Requirements Advisor
- 5 How to Write an Effective Product Requirements Document
- 6 Functional vs. Non-functional requirements
- 7 What Are Non-Functional Requirements and How Do They Impact Product Development?
- 8 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 9 8 Do’s and Don’ts for Writing Requirements
- 3. Requirements Gathering and Management Processes
- 4. Requirements Traceability
- 1 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 2 How to Overcome Organizational Barriers to Live Requirements Traceability
- 3 Requirements Traceability, What Are You Missing?
- 4 Four Best Practices for Requirements Traceability
- 6 What Are the Benefits of End-to-End Traceability During Product Development?
- 5. Requirements Management Tools and Software
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- 8. Project Management
- 9. Measuring Requirements
Adopting an Agile Approach to Requirements Management
The complexity of products is rapidly growing, and as a result, the number of requirements needed to satisfy client goals is also expanding. This makes the documentation process time-consuming and potentially risky. In this chapter, we examine how to take an Agile approach to requirements management.
Existing approaches to requirements management (RM) aren’t always flexible enough to meet stringent expectations and provide a single source of truth. Everyone involved with a project requires maximum visibility to understand what you’re building – and why.
One study found that the majority of design teams admit that they don’t have a requirements management system in place, and instead rely on cumbersome emails and shared documents. Furthermore, only 15% of teams surveyed had invested in a dedicated RM solution.
Teams that are frustrated with rework, feeling stuck in unproductive collaboration and not moving as fast as they could benefit from adopting an Agile approach to requirements management.
What is an agile approach to requirements management?
There isn’t a commonly agreed upon definition of agile requirements management or a single set of processes that will automatically make you agile if you implement it. However, there are concepts, processes and tools that support an agile approach to requirements management.
The foundation of an agile approach to requirements management is rooted in flexibility. Flexibility means you can easily iterate and make changes, so that you end up with a more accurate outcome and avoid off-target deliveries and missed deadlines.
Agile requirements gathering is focused on developing the product faster while addressing customers’ needs more accurately. Collaboration is critical; everyone on the team must have a firm understanding of the customer’s true needs and how they affect RM.
In contrast, teams that don’t use agile requirements are susceptible to unproductive work time, a lengthy review process, excessive rework, and even serious defects in the released product.
RELATED ARTICLE: Requirements Traceability – Does My Data Model Matter?
How does agile requirements management outperform the alternatives?
Agile requirements management is focused heavily on action. With agile, you create a flexible framework upfront, so product implementation is faster and more accurate. In contrast, other approaches, such as the waterfall approach, have less flexibility and are built on a rigid foundation. But why?
The waterfall approach uses a V-shaped development process. The steps involved with coding, such as discovery, requirements, system engineering and architecture, are performed in a specific order. You can’t move to the next step until you’ve finished the one before it. Once coding is complete, you continue to move through the next processes in a specific and inflexible order.
The strategy behind this approach is that you do as much work as possible upfront, and any decisions made during the early project stages are adhered to closely, without much room for change. Moreover, requirements and design often don’t go through testing until the end stages of the development process, so any potential changes show up late in the development cycle, and therefore are more time-consuming to fix.
Agile requirements management is built on the principle of flexibility, so any potential challenges are identified and resolved much earlier in the process, minimizing expensive and costly rework. A few benefits of the agile approach include:
- Improved product design and delivery. A recent report suggests that best-in-class RM solutions can significantly improve product design and delivery for agile development teams. “In the face of increasing regulations, connected products for the internet of things (IoT), and scaling Agile practices, AD&D [application development and delivery] leaders long for something to bring traceability and auditability to their processes without sacrificing speed.”
- Improved traceability. The right RM solution can enhance development transparency through traceability. Traceability empowers teams to perform impact analysis more readily, which is critical to product development.
- Achieve quicker time to market. Teams are facing more complexity and pressure to comply with industry regulations, and need to measure customer value to search, track and connect interdependent requirements. Achieving faster time to market requires that teams collaborate faster and more effectively, working to build traceability requirements and test cases.
As you work to understand how an agile approach to requirements management benefits your team and customer, it also helps to have a basic understanding of the agile requirements lifecycle and how it works.
Designing with greater flexibility through the agile requirements management lifecycle
The agile requirements management lifecycle is focused on clearly defining a project’s scope, so that you better understand what needs to happen to meet the desired end goal. It provides a high-level understanding of business goals, and outlines what is needed for the project to be a success. Consider taking the following steps:
- Understand user stories. User stories give you powerful information about the problem you’re trying to solve. A user story is a quick description of everyday use cases and might include a few sentences about how the user expects the product to perform. A template might be something like this: “As a [role], I need [product] to do [goal of the software] so that I can [benefit of the product].”
- Outline the most important requirements. Identify what requirements are most essential based on the high-level business strategy. These requirements may be supported by user stories, functional requirements and more based on the specific client goals.
- Transform to product features. This stage is about fine-tuning and translating the details that you’ve gathered into product features. The development team collaborates to ensure that any requirements are easily understood by anyone working to implement them. User stories are linked to features and tasks, so that developers understand what they need to do – but also why they are doing it.
Agile requirements management helps give you a foundation on which to build, and best practices arm you with strategies that are proven effective at helping you move in the direction of agile.
2. Collaboration and Buy-In
It’s difficult to get a company to agree on requirements, particularly for large projects with many stakeholders. In practice, it’s not necessary to achieve consensus through compromise. It’s more important to have team buy-in (before or after management approves the project) so the development process can move forward. With buy-in, the team backs the best solution, makes a smart decision and does what is necessary to move forward with the requirements management process.
Team collaboration is key to establishing good requirements. Collaborative teams work hard to make sure everyone has a stake in the project and provides feedback. When there is a commitment and understanding of project goals, team members tend to support other’s decisions. It’s when developers, testers or other stakeholders feel “out of the loop” that communication issues arise, people get frustrated and projects get delayed.
RELATED ARTICLE: Requirements Traceability – How to Go Live
3. Traceability and Change Management
Requirements traceability is a way to keep everyone in the loop. It organizes, documents and keeps track of all requirements, from initial idea to testing. A simple metaphor for traceability is connecting the dots to identify the relationships between items within a project. The following figure shows an example of a common downstream flow.
Companies should be able to trace each requirement back to its original business objective throughout the development process, not merely after it’s complete. By tracing requirements, companies can identify the ripple effect changes have, see if they have completed a requirement and if they tested it properly. With traceability, and by managing changes effectively, managers gain the visibility to anticipate issues and ensure continuous quality.
Traceability also makes sure the product meets all the vital requirements that come from different stakeholders. By tracing requirements, all team members stay connected to each other and to all interdependencies. And by managing changes well, a company can avoid scope creep — unplanned changes that occur when requirements are not clearly captured, understood and communicated. The benefit of good requirements is a clear understanding of the product and the scope involved. This leads to a better development schedule and budget, which prevents delays and cost overruns.
4. Quality Assurance
Getting requirements right the first time means better quality, faster development cycles and higher customer satisfaction with the product. Concise, specific requirements can help companies detect and solve problems earlier rather than later, when they are much more expensive to fix.
Research has shown that project teams can eliminate 50 percent to 80 percent of project defects by effectively managing requirements. In addition, according to Borland Software (now Micro Focus), it can cost up to 100 times more to correct a defect later in the development process, after it’s been coded, than when it’s still in written form.
By integrating requirements management best practices into their quality assurance process, companies can help teams increase efficiency and eliminate rework. According to the Carnegie Mellon Software Engineering Institute, 60 to 80 percent of the cost of software development is in rework. In other words, development teams are wasting the majority of their budgets on efforts they didn’t perform correctly the first time.
Requirements management best practices can appear to be a complex topic, but at its core, it’s a simple concept. It helps teams answer the question: Does everyone — from business leaders to product managers and project leaders to developers, QA managers and testers — understand what is being built and why?
When everyone is collaborating and has full context and visibility into the discussions, decisions and changes involved in product development, they maintain high quality and almost always ensure success.
In This Webinar, We Discuss Reducing Risk in Product Development
Live Traceability™ is the ability for any engineer at any time to see the most up to date and complete up and downstream information for any requirement, no matter what stage of development it is in or how many siloed tools and teams it spans.