Contextual inquiry techniques in requirements gathering

Gathering software requirements is one of the most challenging tasks software development managers face. One technique to overcome the challenges is to observe or experience the processes which the application will be written to address using a technique called contextual inquiry. We explore this technique and show how it can be used to overcome some of the typical issues encountered with gathering requirements.

The history of contextual inquiry

Contextual inquiry originated in the mid-80s as a response to companies getting frustrated with requirements gathering efforts in software development. Users were frustrated with software that was delivered but didn't address their real business problems. Software developers were frustrated that the users couldn't articulate what they needed well enough in the beginning, but then complained when the software was delivered. The bottom line was that the business problem wasn't solved by the software delivered.

Understanding what the users do in their jobs and deriving or augmenting requirements is the key concept behind contextual inquiry. Users may not be able to articulate precisely what they need in requirements gathering exercises. What the users want may be very different from what they actually need. Observing users in their natural work setting, and even performing their work for a brief period of time can make sure that the requirements you gather is what they actually need to do their jobs. This is the contextual in contextual inquiry.

Contextual inquiry was pioneered by Karen Holtzblatt and Hugh Beyer in the 80s and 90s as a requirements gathering methodology, a result of their software engineering experiences at Digital Equipment Corporation (DEC) and beyond. Subsequently, they extended these techniques into software design called Contextual Design. Also, the emergence of UML (Universal Modeling Language) provided a nice way of capturing the results of contextual inquiry and similar techniques.

Typical problems with requirements gathering

Users may know what they want, not what they need – Users may always express requirements in terms of how they do things currently, the current as-is business processes. But these may not be the optimal way to do their current jobs. Requirements gathered this way may be institutionalizing the existing state including possible inefficiencies. This is called paving the cow-path, evoking an informal path in the meadow created by meandering cows.
Business users may not reflect customer requirements – Business users may express requirements only in terms of their work processes. This may or may not be in the best interest of a company’s prospects and customers. Requirements need to strike a balance between making it easy internally vs. making it easy for customers.
Users may not know what’s possible with technology – Users may always be expressing requirements in terms of their own knowledge of technology. Information technology evolves so fast that tools that were used even five years ago may already be obsolete. You have new computing platforms like smart phones and tablets replacing laptops and desktops. A decade ago they were mini-computers and a decade before that, mainframe computers. Requirements need to look to the future and plan for this rapid evolution in technology.
Users may not have visibility into requirements for upstream and downstream business processes – Requirements gathering should be in a holistic context, with allowances made for upstream and downstream business processes. Eliciting requirements from only members of a certain division or department may reflect only their requirements and have no context with respect to inputs from upstream business processes and outputs to downstream ones.

The contextual inquiry process

The contextual inquiry process consists of the following broad steps:

Gathering background holistic information – Requirements gathering needs to incorporate long-term goals of the company and not just the current work practices. Contextual inquiry has as the first step, collection of background information like business strategy, product development plans and a general idea about the requirements needed in the future. This is to make sure that long term goals are accommodated along with daily work practices.
Gathering communication flow and process sequences – During contextual inquiry, it pays to actually perform the job functions of the users for a short period of time to get a sense of how communications and processes flow. Doing this with upstream and downstream business processes will also provide a good idea of who feeds information to the current process, and which business processes outputs are fed out to. This can overcome the isolated requirements gathering problem and provide a good contextual grounding. Individual anecdotal work practices cannot be mistaken for general, across the board, common ones. Interviewing multiple users is necessary for this.
Gathering artifacts and physical work space details – Physical artifacts like forms, screenshots of existing systems and process flow diagrams, if they exist, are to be gathered and included in the requirements exercise. Getting a sense of the physical work space in which users perform their work is important, since it can point to some special requirements that may not have been gathered otherwise. For example, if users work from home or remotely in addition to the office, a browser-based interface may need to be part of requirements.

Benefits of contextual inquiry

Here are some of the benefits of contextual inquiry as a requirements gathering tool. You will be better able to:

Get requirements that balance users with business goals and customers.
Get requirements that enable agreement between IT and business.
Support the way users want to work.
Capture hidden, future requirements and thus enable better planning for the future.
Get to what users need, not just what they want.

Conclusion

Yogi Berra said, “You can observe a lot by just watching!” Nothing captures contextual inquiry better than this quote. Contextual inquiry may help IT professionals understand what a business user is trying to accomplish by getting the context in addition to the requirements. Analysts accomplish this by spending time at the work place, doing the jobs the users do for some amount of time. The overall business, as well as the work context, enables IT to have a longer term holistic view, leading to higher quality requirements.