[The introduction of the Stakeholder Requests should provide an overview of the entire document. It should include 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 requests. 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 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 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 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 interview effectively. 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 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Stakeholder Requests. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Stakeholder Requests. Each document should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]

1.5 Overview

[This subsection should describe what the rest of the Stakeholder Requests contains and explain 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? For whom?

· How is success measured?

· Which problems interfere with your success?

· Which, 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?]

Ask for each problem:

· Why does this problem exist?

· How do you solve it now?

· 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 on-line 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]

· Ask for each suggested problem:

· Is this a real problem?

· What are the reasons for this problem?

· How do you currently solve the problem?

· How would you like to solve the 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 support the product, or will others support it?

· 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 labeling and packaging requirements?

Other Requirements

· Which, if any regulatory or environmental requirements or standards must be supported?

· Can you think of any other requirements we should know about?

10. 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?

11. Analyst’s Summary

[Summarize below the three or four highest priority problems for this user/stakeholder]