Houston, We Have a Validation Problem
If there are issues or deficiencies with requirements, they should come to light in the validation phase
By: Chip Carey
Mar. 4, 2011 01:30 PM
Going on 14 years now, I've made my living working directly or indirectly with software requirements. Early on, I researched, documented, communicated, and managed requirements for a startup developing a "green fields" software system targeted specifically for the full-service hotel industry. The remaining 11 or so years between then and now, I've worked primarily for vendors in the SDLC tools and process space with a direct focus on Requirements Definition & Management (RDM). In this capacity I've worked with hundreds of organizations analyzing their RDM processes, tools, and deliverables in an effort to help them gain improvements. All during that time our own industry analysts have reported a very discouraging failure rate for IT projects and consistently listed deficiencies in the requirements arena as the major contributor.
Various professional organizations and processes may call them by different names but effectively, as analysts, we must execute our role in four primary areas of focus:
It isn't always this neatly defined in crisp, linear fashion. There are additions, deletions, and changes along the way and those come under the "Requirements Management" umbrella. However, when you boil those down, you are left with smaller iterations of the same four steps.
Obviously, some analysts are better than others. That's true in any profession. However, I've never been able to pinpoint project failure to specific deficient individuals working on requirements. In fact, to the contrary, I've often seen project failure with analyst teams whom I considered mature, skilled and very capable. Yet, requirements were deemed to have played a large part in their project's failures.
It has since occurred to me that it really shouldn't matter how capable or skilled the analyst or what the quality of their requirements is. If there are issues or deficiencies with those requirements, they should come to light in the validation phase. By definition, this is exactly why this phase in the requirements process exists. Though I won't deny that as an industry, we suffer from a requirements problem, I'll be more specific and declare we have a requirements validation problem.
Why is this? Make no mistake, the business signs off on the requirements, otherwise these projects wouldn't proceed. But that does not signify that the requirements have been totally consumed by the business with meaningful and complete understanding. I would argue that rarely happens and that this is the weak link. Based on the vehicle we leverage to document and communicate requirements, I don't believe the business is capable of consuming what we present to them, not fully anyway and therein lies our problem.
The vast majority of development organizations leverage either MS Word or some combination of Word and other MS Office products (PowerPoint, Excel, Visio) to document and communicate requirements. I've frequently seen requirements documents that were hundreds of pages long, with references and pointers directing to information in other sections or to other documents. As an analyst, it's easy to forget how familiar we are with this content. After all, we created it. It's our baby. We know what each section holds and how various elements are supposed to relate to each other. We've been through it, arranged, and organized it countless times before we present to the business. We think it tells the full story but we are not the ultimate judge as to whether it is all correct, complete, unambiguous, etc. The business holds that power and that power should be wielded during requirements validation. But the reviewers on the business side are not intimately familiar with the requirements and in fact struggle to make sense of everything that is documented. There's simply too much information, all of it interrelated, that needs to be compiled into a larger understanding than simply reading individual requirement statements here and there.
I like to use an analogy from Hollywood when discussing this scenario where I equate the analyst to a screenwriter, tasked with researching and documenting all the details of a production: scenes, sets, costumes, dialog, entries, exits, etc. But Hollywood doesn't sell screenplays to the general population nor to movie critics at large. Instead, Hollywood converts the screenplay into a movie and this is the vehicle more readily consumed, understood, and ultimately judged.
If the analyst is writing their requirements screenplay in MS Word, how does he or she compile it into a movie for the business to consume? Unfortunately, they can't. The reality is MS Word was never intended to meet the needs of the RDM process. Analysts simply inherited these general business productivity tools in the absence of professional tools designed and developed to meet the specific needs of their profession. However, there are such solutions available today that allow for the entry and management of various artifact types (textual requirements, use cases, actors, UI mockups, business process diagrams, etc.), relating these altogether and then compiling them into a "single version of the truth" simulation that will bring the requirements to life.
Developers have had their specialized IDEs (Integrated Development Environments) for decades, a workbench where the specific needs of their job are at their fingertips. Is the source code more important than the integrity of the requirements it meets? Last, industry analysts estimate that on average, 40% of our product budgets are consumed by rework as a result of requirements issues. I smell a very good business case for arming analysts with a 21st century tool kit, don't you?
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week