Interviewing for Requirements Gathering

Franck Binard:
Software Correctness and Safety Laboratory

The application that will be specified based on the requirements that are gathered should add something to the efficiency of its user's processes. In other words, not only should it support the user's processes, it should also streamline them.

The First Part of the Interview (The process AsIs)

For each process in each role related to the system for which requirements are being gathered, ask the officer to describe:

• The stages of the process. Note that some of the stages may be conditional on previous stages. There is a partial order relation that often needs to be exhibited (what can be done concurrently, if there is a critical path then describe). Most people tend to not be consciently aware of it
• The data that is needed to complete each stage and how that data is acquired and routed to the officer
• The communication/documentation that comes out and in during each stage (what and to whom)
• Who and what systems she interacts with

Remember that because the user is describing her daily business, she might forget a lot of what she does because she might do a lot of it automatically. The more she'll talk, the more it will comes out (so make her talk). Then ask her specific questions about her process.

The Second Part of the Interview (The process ToBe)

In that part, ask the officer to work with an imaginary dream system that perfectly support her functions. By then, she has a description of her daily functions and it is still fresh in her mind. Map the system with her based on the 1st part of the interview. Usually in that part, focus on the order in which the events could be happening to minimize duplication (especially of data entry). Find out what sort of verification needs to take place and when. I try to focus on a "submit" point after which the Process is complete.

So:

• What needs to be done before the submit point ?
• What is the data that needs to be entered ?
• Who needs to be consulted?
• Communications that have to be sent?
• Peripheral steps?
• What needs to happen at the system level (automatic) after the submit point in order to complete the process? [Try to stick as much of the process as possible in that category]

Don't be afraid to repeat the same things several times, asking the same questions and going back to parts that you've closed off. It only gets better the more time is spent on it.

At this point, also start making suggestions. Two things can happen:

• Sometimes: This is a good suggestion = incorporate in process
• Often: This is a bad suggestion = MAKE SURE YOU UNDERSTAND WHY!!! Making a bad suggestion is indicative of something I didn't understand or is missing in the 1st part of the interview. It's an opportunity for correction and clarification. It's always more useful than "good" suggestions

Remember, in that part, the officer is imagining herself as a user of a system that is perfectly integrated with her job and does exactly what she needs it to do to make her job simpler. This is what she should be describing, not what is possible and not what is better for the organization or for other people. These are decisions and they will be made at another time/place