Where is requirements management heading in the next five years?
Richard_Watson 270001D9R3 Comments (2) Visits (8557)
To predict the future of Requirements Management (RM) tools I think it’s important to take a brief look back in history and see if we can spot any important trends. Requirements Management tools differentiate themselves from “typical” documents or spreadsheets by managing distinct, uniquely identifiable statements—called “Requirements”—and dependencies between different requirements—called “links”. Tools to specifically manage requirements have been around since the early ‘90s (starting with QSS DOORS and Rational Requisite Pro). In the first ten years of their lifetime requirements tools justified their existence by the cost savings on understanding and managing the scope and complexity of systems development. There was no real drive to connect requirements to the rest of the development lifecycle or, if there was, the main emphasis was to work out how to get other tools’ data into the RM system so that the traceability could be managed.
In the late ‘90s it became popular to outsource parts of the development lifecycle to other sites or even countries. At this time web based applications were pretty primitive in allowing distributed team access to a single source of information, so data exchange became a hot topic i.e. understanding how to handshake information to 3rd parties and then bring their data back to the “home” database. Bespoke functions were provided in the RM tools which were later replaced by standardised approaches for data exchange with AP 233 and, more recently RIF or ReqIF (Requirements Interface Format).
10-15 years ago there was a shift towards Application Lifecycle Management (ALM). We had good techniques to understand, define and manage requirements but the systems being developed were becoming more and more complex. “Poor requirements management” or “a lack of control of project costs” were still being cited as the reasons for project failure. I would argue that many of these project failures were due to a disconnection between the requirements and everything else being developed to meet them. As the understanding of what was needed in a project changed, these changes were not accurately controlled or reflected in associated development plans or even the originating requirements. For requirements management to be successful, the integrations between RM tools and other development tools needed to work effectively without requiring effort from those deploying and using the tools. Organizations began to demand that fragile “integrations” between RM tools and development tools became more stable and better able to support the scale of projects on which they were deployed. Organizations came to the realization that their users wished to purchase best in class tools and simply expect those systems to work together with standardized integration techniques. Within the last 5 years huge advances have been made through Oasis Open Service for Lifecycle Integration (OSLC) to provide open tool integrations that do not require the user to understand the integration technology.
The increasing scale of projects has raised the importance of reuse, parallel development and variant management. In many industries projects are never initiated from scratch but are variants of work previously delivered. The traditional approach in RM tools has been to identify a starting point in an existing program and make a copy to start a new version or variant. This “clone-and-own” approach has proved to be a fast and effective way to make new projects quickly but ends up with a huge amount of duplication and redundancy. It’s typical to find that the amount of change between variants is as small as 5% - 10% of the requirements data. Organizations can end up with a large number of variants and find that the majority of data in the tool has become redundant and unmaintainable. We now come on to the topic of reuse. In the immediate term (next three years) I can see huge progress being made in managing variation by understanding the changes being made. It’s not just about the requirements. Progress will be made in relating versions of requirements and versions of other lifecycle entities such as test cases, design, software versions and so on. To a software engineer this is simply configuration management, however success will hinge on its acceptance by engineers in other domains who don’t consider configuration management to be their concern.
Now we come to an entirely different dimension to the conversation. The rise of agile approaches changes the way requirements and RM tools are used. The software industry has, in the last few years, been going through a radical shift from waterfall to iterative and agile techniques and this demands more agility in requirements processes. Before requirements tools came into use there was a perception that requirements were written once before development started, and then never revisited for updates or maintenance. Requirements tools have challenged this approach by making requirements relevant to each stage in the development lifecycle. The introduction of agile techniques challenges the way we use RM tools to write requirements. Agile requirements are written “little and often” rather than “systematic and formal”. Requirements will be written “just in time” for a particular Hill or Sprint and this could well change the form requirements take.
And finally… Collaboration, communication and end user productivity is the key. We find that our children communicate more effectively with their friends through online services than our industry does using corporate tools. Within organizations using RM tools, we typically find many people who still don’t use the tool and pass documents, spreadsheets or even emails around to understand what to do next – and give the result to the RM tool user, if they remember! There are two key reasons for this. Firstly, a mind-set shift is required of users to transition from conventional office documents to an RM tool. While the formality and enforcement that RM tools provide is beneficial, the user interface and experience needs to be inviting and accessible to new user communities. Secondly, the tool must be available to all those who may need to work with requirements. Conventional ‘thick-client’ solutions can be hard to manage in complex, geographically diverse and rapidly-changing teams. Thankfully, the software industry is changing rapidly, moving more tools online within web based environments increasingly deployed via hosted cloud environments. The technology for such online tools is developing quickly, sweeping away the restrictions of earlier implementations.
In summary the future of RM tools is vibrant with some clear indications of what is likely in future. RM tools will become far more approachable and better integrated with daily development activities, empowering organizations to succeed with agility at scale.
Product Manager, IBM Requirements Management tools, 2001-present