The future of requirements gathering

The decade of 2010 and beyond offers promising changes for requirements gathering.  I see a few key "themes" emerging:

No More Requirements "Super Heroes"

The requirements management process within companies will become more standardized and repeatable.  The success of a project will not depend on "Super Hero" consultants or employees needed to "champion" the process. 

Requirements engineers who are very experienced and skilled at facilitating requirements JAD sessions, however, will be as valuable as good project managers and good developers.    Skilled analysts will be used rightly and less experienced analysts will be given assignments with lower complexity and less scope. 

Easy to Use Requirements Management Tools

Projects will be formed quickly, results accomplished, and then new teams with different skills formed for the next project.   Requirements management tools must be easy to use - so easy that barely any training is required (or at best, online training). 

Standardization

Processes will become more standardized.   Requirements engineers will train and qualify for industry "certification" of their skills.    Unfortunately, for those who enjoy the "craft" of requirements engineering, they will seek other occupations as requirements management becomes more administrative and routine.

Emergence of the "Modeled" Enterprise

Businesses will evolve from a "project" orientation to an overall model of the enterprise.   Key business processes will be "modeled" to support strategy.    Changes to the business model will involve "checking out" process models from a change management repository, then "checking in" future state process models.    

Businesses will maintain process models for key business processes in the organization.   Changes will be viewed as "scoped releases" of change to the overall enterprise, not as individual free standing projects.

Challenges Ahead 2010 to 2020 

I do not believe we will achieve a "utopia" of requirements management in the next decade. Businesses will continue along a path of maturing their ability to manage business processes and technical changes in a predictable, repeatable way. 

We will become more "economical" however.   Changes to many business processes affecting the enterprise will be modeled and accepted by key stakeholders in a matter of days rather than weeks or months. 

Complex changes to the enterprise that affect different departments, vendors, partners in the value change will occur on a regular basis.   Our ability to manage and implement these changes quickly and correctly will be key to staying competitive both nationally and globally.

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.   

Gathering Requirements in the 1990's

I worked as a business analyst on a large project in Australia in the early 1990's.   I recall being given a PC, replete with Windows, MS Word, Excel and email.    Our project had document templates for every deliverable.   At first I struggled to learn the Windows environment while trying to complete project deliverables at the same time. 

Again, projects were very "data" oriented.   The database design was quickly done first, integrating various "views" of the data provided by users.   These "views" (existing screen snapshots, report layouts, transaction layouts, etc.) were normalized into third normal form and then integrated into an overall project data model. 

Requirements were essentially paragraphs of information describing various "features" of the system:  an interface, a page layout, a report, etc.    The requirement document (usually called a "functional specification") included a data model that describes the limited view of the data that the feature used. 

Towards the late 1990's I started hearing about "use cases".   This was primarily considered a "web-oriented" technique.   A few people were experimenting around with it, however it was not widespread.   It wasn't until 2001 that I'd start working with use cases and requirement statements in a serious way.