Last week I wrote about how to analyze existing documentation to gather requirements.  Today I am writing about how to use interviews to gather quality requirements.  Most of you have probably used interviews in the past, but I hope this blog entry can provide some additional information that you may find helpful.

Interviews can be with one person or a group of people.  It is important that if you conduct interviews in groups to make sure that one person does not dominate the conversation and that everyone gets a chance to respond.  The way that interviews differ from brainstorming, requirements workshops, or focus groups is that they are a more formal interaction.  A lot of preparation is needed before conducting interviews, but they can be a great source of information.  There are three main phases to the interview process.  

• Prepare for the interview
• Conduct the interview
• Post interview follow-up and confirmation

If business or IT users insist that their definition is good and everyone knows what they mean when in fact that is not the case, the strategies below may help.

1. Provide examples of unclear vs. clear definitions

Users who are intimately familiar with their business process and supporting systems may not understand the point of specifying exactly what they need. To them "the ID of the customer" is a perfectly acceptable definition of "Customer ID." Or, the IT representative may give a definition that works for them but no one else, such as "the primary key of the customer table". It will help both to see examples of what is needed in order to have a workable definition to support data warehouse population and use of the data.

If you are reading this blog, you more than likely have a history with the challenges a consultant faces surrounding the political and social environment of the client worksite. At one such client, I was thrust into a volatile situation that had grown from a failed bonus system that had inaccurately calculated payments to its union employees. By the time the miscalculation had been discovered, it was too late; some workers had received too little, while others too much. The union works were greatly upset by having their pay deducted to make up for the mistake caused by the client’s poor implementation of the system. The issue was not a defect in the system created; in actuality the system operated precisely as it was designed.

I’ve often thought that conceptual data modeling was an underused tool in the arsenal available to requirements analysts, and in a recent conversation I found that many were surprised that it would be used in the requirements phase at all.  Checking the Business Analysis Body of Knowledge (BABOK) I found data modeling listed among the tools available to requirements analysts to “to describe the concepts relevant to a domain, the relationships between those concepts, and information associated with them.”  There’s also Steve Hoberman’s excellent book on the topic, Data Modeling for the Business, an introduction to data modeling aimed at a business audience

Schedule pressure can cause us to gather requirements before the stakeholders are fully ready to define what they really would like.  So in order to meet the deadline we may gather a high-level requirement such as “The system shall capture additional data from the client on the screen XYZ”.  This may be used as a placeholder to be further defined during system design or development.  It may seem harmless to just put in this placeholder; however, it may end up causing more harm than good to the project in the end.