Each and every step of the requirements management process is an error-prone, yet crucially important stage of software development.
From defining requirements to analyzing their test coverage, the requirements lifecycle is a rocky road for most development teams. In fact, statistics show that inadequate requirements management is the number one reason for failure in (embedded) software projects. Overspending, running overtime, or quite simply failing to satisfy demands could be the results of an inadequate requirements management (RM) lifecycle.
Therefore, drawing ideas from tried and tested best practices can really help enhance your RM processes, which could hugely affect your bottom line. It's an opportunity not to be wasted.
Recommended blog post:
Developing requirements in collaboration with all stakeholders
The first and most fundamental step of your requirements engineering process will be to capture, define, agree on, and finalize the requirements of your end product. Not surprisingly, this is also where a good portion of the common RM problems are rooted.
When eliciting requirements, it tends to be difficult to capture the right requirements, and to phrase them concisely, accurately, and unambiguously. The fact that truly fitting requirements are a result of widespread collaboration among various stakeholders makes the process all the more difficult.
There are several practices out there for enhancing collaboration, and for implementing some sort of "quality control" on how requirements are defined. Some teams use real-time chat or email to gather requirements, finalize them via lengthy meetings, then simply save requirements to Word docs. And since emailing these Word docs around tends to make things even more chaotic, current "best practices" include the use of a shared local folder or Google Drive.
In case stakeholders manage to agree on a final version, they baseline that requirement, and it's considered good to go. Right, but go where exactly? Trying to find out why a specific requirement was defined in a certain way is pretty difficult. You'd be tempted to check the conversation history, but alas! it's nowhere to be found. A lot of development teams choose to manually copy and paste relevant messages to their requirements' Word docs. It is a solution of sorts, even if an immensely wasteful one. Working best practices, of course, revolve around using dedicated tools to record and manage all the necessary information conveniently or even automatically.
Managing requirements throughout the lifecycle
Such a fragmented process means there is no single source of truth for requirements other than that shared folder. However, controlling changes and managing issues remains difficult. How do you retain older versions of a requirement in your shared folder while making sure everyone uses the most recent version? As your folder structure gets more elaborate, the chance of human error increases exponentially.
Orchestrating the work of all those involved in the approval process requires huge effort. Some companies still consider time-consuming meetings the go-to solution for approving requirements. Others try to implement predefined (online) approval processes, but enforcing the necessary rigour is often problematic.
Once requirements have been finalized, developers will recognize that the source of that same old headache has just turned into something new: it is now the lack of traceability they need to worry about. As requirements are decomposed into tasks, being able to record relationships between these two (or, in most cases, dozens of) distinct items becomes a challenge. Using sophisticated Excel sheets is the ingenious, yet mind-bogglingly inefficient standard solution.
At this point, companies that are able to afford such investments will turn to cheap or even free single-point software tools. They are now able to define accurate requirements, and keep track of them in an organized manner, with minimal investment. What a relief! Updating these software tools is, of course, out of the question due to potential compatibility issues. Development can now begin.
Traceability from requirements through to testing
With the code having been delivered, you may think that you no longer need to worry about managing your requirements. In that case, however, you'd fail to understand and realize the benefits of requirements-based testing, or at least those of executing test coverage analysis. Without end-to-end traceability, how would you find out what portion of your requirements have been covered by test cases?
The standard solution for keeping track of test results and bugs, and their associations with requirements is, of course, another spreadsheet. Juggling all these sources of info, keeping them up to date at all times, and ensuring end-to-end traceability – if you've read this far, you know what all that feels like.
At this level of complexity, using isolated single-point tools for various purposes just won't cut it, as it will only worsen the disorder in your development lifecycle. To eliminate the chance of error, you'll need to enhance transparency and collaboration, and limit manual processes in requirements management. In order to reap the benefits of collaboration throughout the lifecycle, you will need to carefully organize and manage development data in a straightforward manner, through a platform that allows access to everyone.
One of the most highly valued RM best practices among innovative, global high-tech companies is using codeBeamer ALM. Our clients, including Daimler, LG, Samsung, Medtronic, and others, have realized that they can't afford to manage their requirements using unstructured, error-prone, cumbersome ways. Instead, they opted for eliminating waste, cutting complexity, and automating collaboration in a fully controlled way using our advanced Application Lifecycle Management solution.
To learn more about reshaping your requirements management processes, watch our webinar from 1 Feb 2017, download our eBook below, or get started with codeBeamer ALM right away.