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 confirm 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.
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, instant messaging apps, or emails to gather requirements, and finalize them via lengthy meetings, then simply save requirements to Word docs. Sending around these Word docs more often than not results in a chaos of various versions – best practices include using a single 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 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 requirements’ Word documents. 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.
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 their headache has just transformed: it’s 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 requirements management. If you were to cut it short, 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 is a problem that developers have long been struggling to find a solution to.
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 get rid of manual processes, and automate whatever you can. In order to reap the benefits of collaboration throughout the lifecycle, you 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, join our webinar on 11 Jan 2017: