Gathering Requirements in the 2000's

I worked on a major healthcare project where "use cases" emerged as the predominant technique for analyzing business processes.  

We carved up a major project into software releases timed to meet major business milestones.   Then, we looked at impacted business processes or new business processes.   We used MS Word to document actors and steps.    Requirements were driven by documenting the differences between existing business processes ("current state") and new/changed business processes ("future state"). 

I started looking at different tools for requirements.  There are tools to harvest requirements from word documents, tools to place requirements directly in requirements repositories.  The success of these tools in the workplace, to me, seemed very dependent on having a "requirements champion" - someone experienced enough to run with a tool and make it successful on a project or within an organization. 

I worked on a project where we documented over 800 high level enterprise requirements, and managed to complete 100 percent traceability to design documents and test plans.  Our project held vendor's "feet to the fire" to prove that their specifications met ALL requirements.   We had many meetings where a major vendor told us they were at 100 percent traceability of requirements to their design documents, whereas our analysis showed they had only reached 13 percent.   We were able to convince the project Steering Committee executives that we were correct by showing that the vendor did not have design specifications for major enterprise systems that needed remediation.   Needless to say, we won the battle and the vendor spent the next four months churning out designs to get to 100 percent traceability. 

The late 2000's has been marked by a tremendous up-tick in requirements process maturity. More companies are coming to a consensus that the requirements phase is the key to a successful project.  Repeatable processes that drive high quality requirements and 100 percent traceability are starting to become more commonplace. 

Companies are now looking at their existing toolset and adding new tools to manage requirements.  These tools either capture requirements from existing word documents ("mechanizing old methods") or involve directly entering requirements into repositories or via outword facing "wikis"  ("new methods facilitated by new tools"). 

The difficulty is still finding the right "requirements champions" to drive implementation of these new tools.   There is still much reliance on the individual rather than the process.    My next blog will talk about the future of requirements gathering.