Overview
Background
Objective
Provide additional context and explain how this product fits into UC’s strategic goals and initiatives and why we are building it.
Personas
Link to UC’s personas for the user, buyer, influencer.
Success Metrics
List project goals and the metrics we’ll use to judge success
Goal | Metric |
|---|---|
Current Challenges / Limitations
Describe the challenges that users face using the current product, alternative solutions, or performing tasks manually.
Benefits
Highlight the main benefits the customer/user will gain by this product
Subscription / Pricing / Billing Impacts
Describe any financial impact this product will introduce (if any)
Beta and Early Access
Describe if beta customers and/or early access is essential for success. If betas are required, there could be a substantial recruitment process required which needs to be anticipated and planned for.
Risks and Assumptions
List any risk or assumptions you have about the users, technical constraints, business goals …
Milestones and Phases
List the project milestones along with how that milestone can be successfully measured.
Number | Description | Success Measurement |
|---|---|---|
Product Requirements
Describe the product requirements that will fulfill the underserved need(s) starting off with the use cases, then specific functionality
Use Cases
Happy Day Scenarios
This is the “happy path” that includes the beginning to end steps the customer/user takes to be successful.
Rainy Day Scenarios
Here is where you describe what to do when things go wrong (e.g., user closes the browser, API doesn’t return results …)
Requirements
Requirement | User Story | Importance | Status | Comments |
|---|---|---|---|---|
Provide a means for UCF super-administrators to specify which authority documents belong to supported state-agencies. | TBD | Not Started | Option 1: create a “dummy” company per supported state-agency and create a list of supported ADs. Ensure state-agency identification is populated in HubSpot which will feed into the reporting engine. Option 2: create table/form … outside of CCH to allow supper admins to specify supported state-agencies and their related ADs. Option 3: ? | |
Within CCH, provide a means for the user to ask for AD recommendations. | P1 | Not Started | ||
After the user chooses the option to receive AD recommendations, gather recommended authority documents based upon the self-identified: 1. industry, affiliation, or both OR
Send the user via email with a PDF attachment for the recommended ADs. | P1 | Not Started | The consolidated recommended ADs is based upon ADs in shared lists and ADs in builds. | |
Once the email is sent, inform the user they should check their email inbox for recommended ADs. | P1 |
Open Questions
List any open questions that come to mind throughout the lifecycle of this project
Question | Answer | Date Answered |
|---|---|---|
Out of Scope / Future Functionality
List the known features that are out of scope for this project or might be revisited at a later time.
As is case with the assumptions, it is important to list these out so that architects and engineers can plan accordingly for these later updates.
Impacted Product Components
If this project is a component to other areas or an update to an existing product, specifically call out where this product will interact with other areas.
User Interaction and Design
Process Flow Diagrams
Links to user journeys, process flow, or other diagrams related to the requirements.
Guides
If there are UI components to this requirement, list the main areas where interactive user guides would be needed.
Additional References
List and link to any other reference sites, documents … that might be important to the reader.