Thursday, October 31, 2013

How to Prepare for Requirements Sessions (Part 2 of 2)

Preparing Questions in Advance

In my last blog back on September 13 I offered the 1st of 2 parts on how to prepare for requirements gathering sessions. I referenced a whitepaper written by Joy Beatty, a VP with Blue Ocean Strategy, for Seilevel, a professional services company that creates software requirements and offers training in software requirements best practices. As I mentioned back in September this whitepaper has proved to be invaluable in preparing for requirements gathering sessions. I presented Mr. Beatty’s thoughts on organizing your time and preparing models in advance if possible.

In Part 2 I’d like to continue with his advice on preparing elicitation questions in advance. Having a pre-written list of questions provides structure – think of those meetings you were sitting in that quickly got off track because somebody went off on a tangent and the meeting owner (maybe even you) “forgot” where you were and struggled to get back on track. Mr. Beatty’s suggestions will enable you to hold more productive requirements gathering sessions. 

“One of the key steps to take prior to a stakeholder meeting is to prepare a list of questions to be asked during the meeting. These questions might be created based upon past experiences or recent meetings with the user. If the analysts know the users, the organization, or the types of issues they face, that knowledge should lead to obvious questions. If the analyst has met with the user already, new questions should be created based upon those original meetings, lessons learned and new issues identified. Also, if draft models are being used, those most certainly should prompt questions.

There are some stock questions that you can use as a guide to requirements gathering sessions. Keep in mind though, each project will need its own unique set of questions, and some of the stock questions listed here will not be appropriate.

How to Identify Actors for Software Requirements

Below are some suggested questions to ask to identify the actors (users) of a system:

    • Who uses the system?
    • Who installs the system?
    • Who trains people to use the system?
    • Who fixes the system?
    • Who starts up the system?
    • Who shuts it down?
    • Who maintains the system?
    • Who creates, updates, deletes information from the system?
    • What other systems interface with the system?
    • Who gets information from this system?
    • Who provides information to the system?
    • Does anything happen automatically at a predetermined time?

How to Identify Use Cases

    • Below are some suggested questions that can be used to identify the list of use cases or system functionality:
    • What functions will the actor (user) want from the system?
    • Does the system store information?
    • Do the actors (users) need to create, update, or delete information?
    • Does the system need to notify and actor (user) about changes in an internal state?
    • Are there any external events the system must know about?
    • What is the actor’s (user’s) overall job?
    • What problems has the actor had in the past?
    • What steps are manual today?

How to Identify Other Paths

    • Below are some suggested questions that can be used to identify alternative sources or exception paths. These questions should be asked at every step of a use case main course:
    • Is there some other action that can be chosen?
    • If X does not happen, what should happen?
    • What if the actor cancels an operation (i.e., closes a window)?
    • What if the actor provides incomplete information?
    • What might go wrong at this step?
    • What if part of the system goes down or is unavailable?
    • Are there any events (or interrupts) that might occur at any time during the use case?

Sit with your users

If your users are extremely busy, and the project involves changes to or replacement of an existing solution, then turn the challenge into an advantage. Sit beside the users while they perform their job tasks. Typically this is a good way to elicit requirements because users cannot always articulate their needs if they are used to completing tasks without thinking about them. This technique will require follow-up meetings with the users, but then those meetings can be prepared for as outlined above, with intelligent questions based on the observations, thereby shortening the time that users are away from their work.

There are many ways in which analysts can prepare for requirements sessions with users. Typically a mix of the above suggestions will work well on any project. These tips will help the analyst and users get the most value out of the available time.”