Requirements Elicitation Techniques Part 9 – Observations

Planning

In many cases of gathering requirements, there is no substitution for actually observing the process as it happens. You will find that often the way things are done contradict what is written in process manuals. These deviations are important as they usually reveal an inefficiency or deficiency in the process, and the user felt the need to employ a different method. This is valuable information for process improvement!

You should be aware that at times just the fact that a process is being observed can make the user change how they usually do things. It is important to make the people being observed comfortable with why they are being observed and the objectives of the observation. Openness and honesty are important. Solicit their input and suggestions.

As with anything project related, there needs to be a plan. You can make a simple form with elements such as:

  • Process Name
  • Observation date(s) and times
  • Observers
  • Location
  • Purpose/Objective
  • Notes
  • Key Findings

The dates and times are important as you need to know if this is considered peak/normal/low volume time. This is a key consideration regarding the observation objectives.

After the observations are complete, you should meet with key project staff and stakeholders to discuss findings and their impact on the requirements.

A reminder that my Kindle book “Project Management For The Real World” is available at

Requirements Elicitation Techniques Part 8 – Nonfunctional Requirements

Planning

In this series so far I have addressed “functional” requirements. These are the requirements that address features, functions and processes for the new system. There are also many requirements that are not related to the features, functions and processes. These are called “Nonfunctional Requirements” and mostly address the quality of the delivered product.

Here are some examples of Nonfunctional Requirements:

  • Performance – Response time, transaction rates, throughput.
  • Operating constraints – System resources, people.
  • Platform constraints – The target platform may have been predetermined.
  • Accuracy – Some applications (e.g. Consumer Data Base) can tolerate some level of inaccuracy, while others (e.g. Taxes) have to be very accurate. This should be agreed upon in advance. Accuracy has a cost so it should be in line with the value.
  • Maintainability – The effort required to make changes. Sometimes this will be sacrificed in order to meet a target date. Your Business Sponsor should be well aware of this decision.
  • Portability – The effort needed to move to a different platform
  • Availability – System up-time. Should specify the maintenance and upgrade windows.
  • Security – Requirements of the protection of the system and it’s data.
  • Usability – How difficult will it be to learn the system? How much training time is needed?
  • Legal – Consult your company’s legal team for these. Your project could involve labor laws, privacy laws, etc.

Your organization may have standard templates for these types of requirements. If not, you should create the templates as part of your project. There should be lots of useful information from previous projects for you to use as source material.

A reminder that my Kindle book “Project Management For The Real World” is available at

Requirements Elicitation Techniques Part 7 – Interviews

Planning

Interviewing is a systematic approach to eliciting requirements. You can interview an individual or a group of people, in a formal or informal setting. You ask questions relevant to the project and document the responses.

Interviewing should not be the only technique you use to elicit requirements. You will not know all the questions you need to ask. That is why I am a big fan of the Event/Response method (I have a prior series of posts on this method). The flow of that methodology creates the questions you will need to ask to ferret out all of the requirements.

In a structured interview, you have a predefined  set of questions. These will be based on how much you already know about the area under study. Here are some sample interview questions:

  • What are the business objectives for this project?
  • What are your biggest challenges?
  • What worries you about this project?
  • Who is impacted (good or bad) by this project?
  • How are they impacted?
  • Are their known changes or projects that impact this one?
  • What business processes are impacted?

When interviewing, avoid “yes or no” questions and pay careful attention to the answers. It helps to have someone document the answers for you so you can focus on paying attention to the answers. They usually will lead to follow up questions that are not on your script. Be prepared to deviate from the script if necessary.

In an unstructured interview, topics are discussed in an open-ended way. You don’t have a script, so the answers are used to spring-board into subsequent questions.

If possible, you should establish in advance a trust and rapport with the interviewee. This will make them more comfortable to be open and honest with you.

A reminder that my Kindle book “Project Management For The Real World” is available at

http://www.amazon.com/dp/B089KRDDVN