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.  

Gathering Requirements in the 1980's

As I walk down requirements "memory lane", I harken back to the 1980's.   What was it like to gather requirements then?

In the early 1980's there was very little "tool support" for the requirements process.    Very few IT workers had access to PC's.  I first started using a PC at work in 1987.    We had a team size of 30 and we had to "sign up" for 1/2 hour blocks to use two PC's.   The PC's had a basic text editor for composing simple documents.  

We also used a PC tool called "Excelerator" that allowed us to manage basic architectural deliverables such as data flow diagrams and functional decomposition charts (they looked like company organization charts, that hierarchy described the functional architecture of an application).   Processes were documented with data flow diagrams, that often zoomed down multiple levels.  

I remember these PC's having 10mhz processors and 256K memory.   We had a 512K "buffering" system that allowed us to print large documents to the printer.   These were very basic PC's, yet their impact on our work was extensive.   We could edit and change documents ourselves and present them again to users!

Business processes were considered "unstable" so the vogue thing was to do "data analysis".  The idea was to interview the customer, review reports, etc. and perform a normalization (third normal form) of the data.    The database and data entry "screens" were developed based on populating the third normal form of the data. 

Many users complained that these "data oriented" systems did not align to the way they did business.   Business users complained that they were just data entry clerks.  We would reply that the data had to be entered so that it could later be reported on and analyzed.    The users were often "forced" to use these systems, as much money had been spent, and at the end of the day they would basically work to capture data, move it to where it was needed and allow for analytical functions. 

It was very typical that the first systems produced by these data oriented methods were not much more than prototypes.   Often the users complained and many changes had to be made until the system was at the minimum "acceptable".    Systems were not as complex as they are now, so requirements were often more simple, yet the methods used results in a "hit or miss" fulfillment of user requirements. 

I remember a timesheet system we developed for a customer.  In the first rendition, the "users" (blue collar folk) detested the system so much they would put a wrench through the screen in disgust.  We'd get plenty defacement of company IT property.   Eventually the system was streamlined so that it became acceptable enough so that damaged equipment no longer was problem and users could enter their timesheets with minimal fuss. 

Requirements were generally written using the Victorian novel approach.  If you wrote enough about it, stakeholders would make changes until they cried "Uncle" and signed off!   There was some movement towards rudimentary requirements statements, as some methodologies enforced the word "shall" or "must" in requirements statements.   Forget structured requirements statements, requirement id's, traceability and use cases - that would come in the 1990's! 

My next blog entry will talk about requirements gathering in the 1990's. 

Back to the Future: Requirements Management Then and Now

The other day I watched (for the nth time) the movie Back to the Future.    Back to the Future reminded me of my first project failure that happened waaay back in 1983 (yes, I was a budding programmer analyst back then). 

I was working with an older gentleman who's job as a project manager was to document the software requirements for a small project started in the engineering department.   The purpose of the project was to develop a small software application to store and track various sampled statistics.

The older man's approach was to document all aspects of the project with voluminous documents, where each word, verb adverb etc had to be meticulously selected.  This approach totally frustrated the younger engineer who was the sponsor of the project.   My older gentleman friend was ultimately let go (he was a contracted project manager) because the young engineer could not stand the older man's approach.  

I was so embarrassed by this failure, even though I did not directly contribute to it, that I put in the back of my mind I would spend the remainder of my career trying to understand this very strange "requirements" phase and see if I could learn how to do this correctly. 

This led to ultimately creating my own company called Software Requirements, Inc. (www.softreq.com) which specializes in requirements management, requirements tool selections, etc.   

Future posts will be a walk down memory lane.   How were requirements gathered in the 1980's, the 1990's and the 2000's.   And finally "where are we now" and "where is this going". 

Please enjoy!