Requirement Elicitation Checklist Template [Free Download]

Editorial Team


Download this free Requirement Elicitation Checklist template and use it for your new project. Scroll down to the bottom of the page for the download link.

1                    Introduction

<The introduction of the Stakeholder Requests provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this collection of Stakeholder Requests.

<Context-Free Interview Script:  Great opportunities exist in our industry to improve application development efforts. Understanding stakeholder or user needs before beginning development is crucial to improving this process. Many techniques are available to elicit stakeholder or user needs. One simple and inexpensive technique that is appropriate for use in virtually every situation is the Generic Interview. The Generic Interview can help the developer or analyst understand stakeholder or user objectives and problems. Armed with this insight, developers can create applications that fit the stakeholder’s or user’s real needs and increase their satisfaction.

The Generic Interview in this template features questions designed to elicit an understanding of the stakeholder’s or user’s problems and environment. These questions explore the functionality, usability, reliability, performance, and supportability requirements for the application. As a result of using the Generic Interview, the developer or analyst will gain knowledge of the problem being solved, as well as an understanding of the stakeholder’s or user’s insights on the characteristics of successful solutions.>

1.1            Purpose

<Specify the purpose of this collection of Stakeholder Requests.

Guidelines for Use: If the Generic Interview is not suited to your needs, feel free to modify it. With a little preparation and a well-structured interview, any developer or analyst can effectively  interview. Here are some hints:

  • Research the background of the stakeholder or user and the company ahead of time.
  • Review the questions prior to the interview.
  • Refer to the format during the interview to ensure the right questions are being asked.
  • Summarize the top two or three problems at the end of the interview. Repeat what you learned to confirm your comprehension.

Do not let the script become overly constraining. Once rapport is established, the interview often takes on a life of its own, and the stakeholder or user may talk at length about the difficulties they’re experiencing. Do not stop the stakeholder or user. Record these responses as quickly as possible. Follow up on the information with questions. Once this exchange reaches its logical end, proceed with other questions on the list. Good luck and happy interviewing!>

1.2            Scope

<A brief description of the scope of this collection of Stakeholder Requests; what Project(s) it is associated with and anything else that is affected or influenced by this document>

1.3            Acronyms and Abbreviations

<This subsection provides the definitions of all terms, acronyms and abbreviations required to properly interpret the Stakeholder Requests>

1.4            References

<This subsection provides the complete list of all documents referenced elsewhere in the Stakeholder Requests. Identify each document by title, report number (if applicable), date and publishing organization. Specify the sources from which the references can be obtained.>

1.5            Overview

<This subsection describes what the rest of the Stakeholders Requests contains and explains how the document is organized>

2            Establish Stakeholder or User Profile

  • Name:
  • Company/Industry:
  • Job title:
  • What are your key responsibilities?
  • What deliverables do you produce?
    • From whom?
  • How is success measured?
  • What problems interfere with your success?
  • What, if any, trends make your job easier or harder?

3          Assessing the Problem

  • For which <application type> problems do you lack good solutions?
  • What are they? <Hint: keep asking “Anything else?”>

For each problem, ask:

  • Why does this problem exist?
  • How do you solve it?
  • How would you like to solve it?

4          Understanding the User Environment

  • Who are the users?
  • What is their educational background?
  • What is their computer background?
  • Are users experienced with this type of application?
  • Which platforms are in use?
    • What are your plans for future platforms?
  • Which additional applications do you use that we need to interface with?
  • What are your expectations for usability of the product?
  • What are your expectations for training time?
  • What kinds of hard copy and online documentation do you need?

5          Recap for Understanding

  • You have told me <List stakeholder described problems in your own words>
    •  
    •  
    •  
  • Does this represent the problems you are having with your existing solution?
  • What, if any, other problems you are experiencing?

6          Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate assumptions)

  • <If not addressed> Which, if any, problems are associated with:

<List any needs or additional problems you think should concern the stakeholder or user>

  •  
    •  
    •  
  • For each suggested problem, ask:
    • Is this a real problem?
    • What are the reasons for this problem?
    • How do you currently solve this problem?
    • How would you like to solve this problem?
    • How would you rank solving these problems in comparison to others you’ve mentioned?

7          Assessing Your Solution (if applicable)

  • What if you could… <summarize the key capabilities of your proposed solution>
    •  
    •  
  • How would you rank the importance of these?

8          Assessing the Opportunity

  • Who needs this application in your organization?
  • How many of these types of users would use the application?
  • How would you value a successful solution?

9          Assessing Reliability, Performance and Support Needs

  • What are your expectations for reliability?
  • What are your expectations for performance?
  • Will you or others support the product?
  • Do you have special needs for support? What about maintenance and service access?
  • What are the security requirements?
  • What are the installation and configuration requirements?
  • What are the special licensing requirements?
  • How will the software will be distributed?
  • What are the labelling and packaging requirements?

10     Other Requirements

  • Which, if any, regulatory or environmental requirements or standards must be supported?
  • Can you think of any other requirements we need to know about?

11     Wrap Up

  • Are there any other questions I should be asking you?
  • If I need to ask follow-up questions, may I give you a call?
  • Would you be willing to participate in a requirements review?

12     Analyst’s Summary

<Summarize below the three or four highest priority problem for this user or stakeholder>

  1.  
  2.  
  3.  
  4.  

Click here to download Requirement Elicitation Checklist template.