The Essential Guide to Requirements Management and Traceability
- 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 Adopting the EARS Notation to Improve Requirements Engineering
- 5 Jama Connect Advisor™
- 6 Frequently Asked Questions about the EARS Notation and Jama Connect Requirements Advisor
- 7 How to Write an Effective Product Requirements Document
- 8 Functional vs. Non-Functional Requirements
- 9 What Are Non-Functional Requirements and How Do They Impact Product Development?
- 10 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 11 8 Do’s and Don’ts for Writing Requirements
- 3. Requirements Gathering and Management Processes
- 4. Requirements Traceability
- 1 What is Traceability?
- 2 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 3 How to Create and Use a Requirements Traceability Matrix
- 4 Live Traceability vs. After-the-Fact Traceability
- 5 How to Overcome Organizational Barriers to Live Requirements Traceability
- 6 Requirements Traceability, What Are You Missing?
- 7 Four Best Practices for Requirements Traceability
- 8 Requirements Traceability: Links in the Chain
- 9 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
- 1 Understanding ISO Standards
- 2 What is ISO 13485? Your Comprehensive Guide to Compliant Medical Device Manufacturing
- 3 A Guide to Automotive Safety Integrity Levels (ASIL)
- 4 Compliance Management
- 5 What is FMEA? Failure Modes and Effects Analysis
- 6 What’s a Design History File, and How Are DHFs Used by Product Teams?
- 8. Project Management
- 9. Measuring Requirements
- 10. Systems Engineering
Conquering the 5 Biggest Challenges of Requirements Management
In this chapter, we cover the biggest challenges of requirements management, and how to conquer them.
As products and software become more advanced, the complexity of projects increases to develop, maintain, comply with standards all while maintaining their initial goals. For many projects, requirements documents can be hundreds of pages and change dozens of times during the development process. That means that teams sometimes spend hours circulating, editing, and tracking changes to a hefty requirements document with the hope that everyone reads it and stays engaged. Sometimes more time is spent reviewing and approving all the requirements than on the actual requirements engineering activities themselves. This can make a significant impact on project FTE and normally does not get budgeted appropriately.
Modern products are multifaceted and multidisciplinary, with hardware, software – plus Bioware, chemistry, and life sciences in the medical device industry –, and various science and engineering approaches coming together in the name of superior customer experience. Many industries — medical device, automotive, and aerospace and defense, for instance — also require that complex product developers adhere to rigorous safety standards and regulations. Companies must work effectively and efficiently if they’re going to grow their competitive advantage. And that all starts with requirements management.
And the reality is, Word and Excel are not enough to manage complex requirements.
The problem isn’t the requirements document itself. In fact, documents themselves are needed to record requirements. The problem is in using the document to manage requirements. Current static tools, such as Word and Excel, don’t support the accelerating development process, the speed of change, and navigating the complicated organizational documentation machinery It’s no longer realistic to use documents to set expectations, communicate project details, and track changes throughout the process of developing today’s complex products.
As the person responsible for ensuring everyone understands what we’re building and why (a.k.a. requirements), you must evolve how you work. You must embrace new techniques and tools to find a better way to communicate requirements and deliver the right solutions while making the process as enjoyable as possible.
Based on our own experience and that of our customers, we compiled the five biggest challenges of requirements management, as well as expert insight into how to conquer each one.
Challenge #1: The 11th Hour Swoop-In
An executive comes to you last minute with feedback that you needed three weeks ago.
We’ve been on both sides of this frustration, and it’s not pleasant for either party. The reality is that managers are busy dealing with a variety of issues and are often forced to focus on what’s most urgent. Also, ideas might be generated after leaders or stakeholders see prototypes and realize that what was specified in the initial requirements document is no longer the best solution.
Expert Tip: Be Open
To prevent the 11th hour swoop-in, you must be transparent and open to feedback at all phases of the project. Give management better visibility and a continuous feedback loop throughout the development process to address issues before it’s too late. Frequent check-ins can help get reactions early. If your team and executive staff are in the same office, this is easier to accomplish. Have a whiteboard or dedicated wall sharing the latest designs in a prominent location, such as a project room or command center. Every day, folks walk by and have an opportunity to react to what they see. Most people respond better to visuals versus written words to understand the user experience.
If you’re a distributed team in multiple locations, as is common today, then a specialized solution that provides everyone a central hub for the project’s requirements, related designs, and Live Traceability™ will help. Anyone, no matter where they are, can see what’s happening as the project evolves and you’ll be able to see any disagreements or potential hang ups before they cause costly rework.
RELATED ARTICLE: How to Write an Effective Product Requirements Document
Challenge #2: Decision Rehashing
Meetings are spent revisiting old decisions or bringing others up to speed.
Decisions may be overturned as new information becomes available during the development process. However, there are better—and more cost-effective—ways to work through these changes than hashing it out in team-wide meetings.
Expert Tip: Be Clear
To manage change well, the whole team needs the full context of the decisions made to understand why things are changing and how those changes impact the project’s scope. People need clarity and understanding to execute at their best.
This applies upstream to your stakeholders and customers so they understand what they’re getting. It also applies downstream to your design, development, and QA teams so they know exactly what to build and test properly.
Modern collaborative solutions exist that can help you capture the healthy debates and ongoing discussions that naturally take place around requirements, without the need for more meetings. People can see what others are saying and add their feedback anytime to agree or disagree, approve or reject, or propose edits to refine the solution.
Also, decisions made in meetings aren’t easily tracked in documents and human memory fades over time. In some markets, such as the medical device industry, the documentation of a decision may also be a requirement. If missing decisions are an issue for your organization, adopt a new technique to capture decisions in line with requirements, and make them easy for the team to view anytime. This will eliminate ambiguity and ensure that decisions about the project are crystal clear.
Challenge #3: Change Tax
Manually sending updates to everyone when something changes.
When executing complex projects, change is going to happen, often for good reasons. As you get deeper into the design and development of a project, you know more than you did at the beginning. Thus, you and your team will think of better ways to build the desired product and modify the requirements along the way. If you try to manage versions and maintain visibility by tracking changes in Word documents, you’ll experience a huge tax on your time.
Expert Tip: Be Iterative
Embrace changes intelligently by connecting the dots, quickly assessing the impact, and automatically communicating changes to the right people involved. You want your entire organization to feel empowered to propose a change if they find a better solution.
The number one reason to adopt Agile within your organization is to create a culture that is nimble so your team can respond quickly and effectively to changing requirements. In fact, the first principle in Agile development is, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Thus, iterating in incremental development as you go.
Don’t get hung up on the labels or the debate of whether scrum or kanban is superior. There is no definitive, one-size-fits-all process. Agile first and foremost is a cultural mindset, not a prescriptive development process.
Effective Agile teams maintain requirements best practices such as traceability, impact analysis, and change management, which are borrowed from traditional methods so they can understand the ripple effect a change has on the rest of the project.
It’s a balancing act between agility and formal control. Some call it a hybrid approach. Again, the labels don’t matter. The key is to find the mix of techniques that works best for your team so you can execute projects while encouraging/welcoming/responding to change.
Challenge #4: Attention Deficit
Creating a detailed 200-page plan that no one has time to read, maintain, or review.
You need to articulate your plan to those included in the product development process, and let stakeholders know explicitly what is relevant to them. The problem is, most people only care about specific parts of the plan at any given time. Some documents are required by regulations. However, if you’re working in documents, you could spend a lot of time creating something few people will read. And, any time an item changes, folks must review the whole thing to find what’s changed and determine each time if it’s relevant to them or not. Eventually, people stop paying attention.
Expert Tip: Be Relevant
Adopt the philosophy that everyone is simply too busy to absorb an entire requirements document. To avoid being frustrated by your organization’s collective attention deficit, relevancy is key.
This is an area where product development solutions can help you break large, complex projects into smaller, manageable parts and let people focus on what’s relevant to them. We recommend you manage the scope of projects item by item to get work done. If you’re curious what we mean by “item,” a requirement is an item. A use case is an item. A test case is an item. A defect is an item.
People naturally work on a list of a few items at a time. It’s how our brains work, and we’re more productive that way. By itemizing the scope of your projects using a solution with a relational database, it will allow people to focus on specific items they are working on and maintain the context of the overall project. Then, as needed for baselines, releases, or milestones, you can group together items and summarize the project via reports or a specification document for a holistic view.
Challenge #5: Mismatched Expectations
Stakeholders think they are getting one thing and are delivered another.
The expectation gap can cause real problems for company morale—not to mention your bottom line. Your development team takes pride in what they created, so when it doesn’t meet expectations, they can feel as though their hard work is wasted. On the other side, stakeholders can feel as though they haven’t been heard or that the development team didn’t understand the request.
Expert Tip: Be Proactive with Traceability
Every project has changes during development, be they additional things to add or the reprioritization of features as the scope evolves. You must be able to document requests, justifications, decisions, agreements, and approvals made by the appropriate stakeholders. And that information must be available to everyone throughout the development process to ensure a consistent set of expectations.
When developing a product or system against a requirement, teams must be aligned with the need, or problem, as stated and agreed upon with the stakeholders. For systems engineers, business analysts, and product owners, requirements traceability (the ability to trace requirements to downstream development, test, verification, validation, and risk activities) is an unquestioned good and an unquestioned need.
Without adding a lot of unnecessary overhead, modern requirements management solutions offer the capability to capture the decisions, reviews, approvals, and electronic signatures to scope changes, as well as provide context, all as part of the natural workflow.
With that level of visibility, everyone can be confident they know the plan, and your development team can feel good about delivering what’s promised. And your launch event can be a celebration of your great work rather than an interrogation of what went wrong.
In This Webinar, We Discuss the Benefits of Modern Requirements Management
A Requirement is a condition or capability needed by a user to solve a problem or achieve an objective.
RELATED ARTICLE: Checklist: Selecting a Requirements Management Tool
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started by filling out this form so we can connect!