Specification Document¶
The Specification document is the primary supporting documentation for most tools. Use this document whenever the tool will require greater than 60 hours of development time or is expected to be long-lived and widely-used.
The Specification document replaces and expands both the Scoping exercise and the Product Definition. You may be able to copy/paste some content from each, but consider taking the time to improve this content.
A template Specification Document is available here (page 3). Download a copy before continuing.
Solution Description¶
Describe the solution in broad terms. This section introduces the tool and allows the reader to develop an understanding of what the tool is and how it will be used.
Context¶
Provide useful background information, including why the solution is required and in what setting the solution will be used. This section is useful in understanding the motivation for building the tool at the time it was built.
Scope¶
Describe which types of problems the tool is intended to solve, and which it is not. Is this tool applicable in one or many business units? Is it internal or client facing? Clarity on the scope will help maintain focus during development.
Goals & Objectives¶
Revise the goals and objectives from the Product Definition.
Goal¶
The goal statement should describe the desired impact of the project. It should relate to your conservation targets. It should be observable. Optionally, it can be measurable and time-limited. The goal is not "to implement the solution", the goal is what happens if the solution is implemented successfully.
Objectives¶
- Objectives describe a desired outcome for the project
- Objectives are not an outline, list of features, are set of use cases
- Try to have at least two and no more than five objectives
Intended Users & User Research¶
Use this section to provide persona descriptions and user hypotheses. Describe how the user hypotheses were or will be tested.
Evidence of Need/Opportunity¶
Use this section to describe the problem scenarios, current alternatives, and the value hypotheses. Describe how the value hypotheses were or will be tested.
Product Description¶
This section should provide succinct and clear descriptions of the various elements of the product, from the user interface to the technology it is build upon.
Intended Uses¶
List and describe the user stories that will serve as the basis for tool development. Be exhaustive in scope but don't worry about being too specific for each story.
Requirements¶
Describe both the user requirements (e.g., skills, training, ability to access sensitive information) and the software requirements for using the tool.
Workflow¶
Describe how the tool will fit into existing or create new workflows. A before/after Journey Map is recommended.
User Interface¶
Provide mockups or wireframes of the user interface. Describe any important style guidance.
Architecture¶
Describe the suite of tools that will combine to create the desired functionality of this tool. Include any related products.
Quality Assurance/Quality Control¶
Describe both the testing approach used during development and the requirements for ongoing quality assurance once the tool is in use.
Limitations¶
Be upfront about any limitations of the tool.
Governance¶
Who is in charge of the tool? How can changes be made? Governance is important both for naming the party responsible for the tool and preventing unwanted changes or derivations of the tool.
Product Support¶
This section outlines the plan for onboarding and supporting users of the tool as well as maintenance and end-of-life plans.
Stakeholder Engagement Plan¶
Developing a solution does not guarantee that intended users will use the solution. Both primary users and stakeholders (secondary users) must be engaged to promote awareness of the product, learn how to use the product, and tailor the product to meet their needs.
Provide a high level description of the plan to keep users engaged.
Communication Plan¶
Describe how you will make users aware of the tool. Consider using multiple communication channels and audience-specific tactics. The table below provides a framework for quickly building a communication strategy.
Communication Plan Table¶
| Objective | Audience | Tactic | Lead | Timeframe |
|---|---|---|---|---|
| Example: Promote awareness of the product | Example: internal USAID | Example: Email blast to key audience | Example: Erik Anderson | Example: Week of final production |
Dissemination Plan¶
Describe where the tool will be made available to users and how users will receive the tool directly. If relevant, describe how users will access updates to the tool.
Adoption Plan¶
Adoption occurs after users are onboarded, increase engagement, and realize sufficient benefits from using the tool to fully adopt it. Onboarding is the first step towards adoption. Engagement entails more substantial or more frequent use of the tool. Adoption describes when the user is using the tool for most if not all of the intended use cases (i.e., not using other tools or workarounds).
The table below will help you walk through this process and test where users might drop off from the adoption curve. Guidance for each section is provided below.
- Desired behavior: Describe what you want your user to do at each phase of adoption. Make sure it is an observable behavior.
- Timeframe: Describe how long the user will be in each adoption phase. For example, behaviors associated with engagement might happen after one month of using the tool.
- Test: Describe how you can test whether users are or are not exhibiting the desired behavior.
- Metrics: Describe the indicators that will be measured to provide evidence of whether, and to what extent, users are exhibiting the desired behavior. For example, a web app may measure number of site visits.
- Red flags: Describe what to watch out for that might indicate users are falling off of the adoption curve at each phase.
- Incentives: Describe any strategies for increasing adoption or mitigating red flags.
Adoption Table¶
| Onboarding | Engagement | Adoption | |
|---|---|---|---|
| Desired behavior | |||
| Timeframe | |||
| Tests | |||
| Metrics | |||
| Red flags | |||
| Incentives |
User Support¶
Describe the plan for providing guidance and technical support. What documentation or guidance will be provided to support users? Who will the user reach out to if there is a problem? How will they know who to reach out to? Primary technical support means support provided directly to the user. This often includes coaching and help with less common use cases. Secondary technical support is needed when the problem cannot be addressed by the primary technical support provider. This typically includes bug fixes and new features.
Maintenance & End-of-Life¶
Describe when, how and why the tool will be updated or new features will be built. Consider what will be required if the technology underlying the tool is updated or sunsetted.
Describe the end-of-life plan. How long will the tool be maintained? Under what set of conditions will the tool be retired? What will the tool be replaced by?
Future Directions¶
This section provides an opportunity to contemplate how the tool might adapt over time and capture any stretch goals that were not achieved during development. This section will be useful when returning to the tool for updates later on.