Overview
Background
Content providers such as CSA, PCI, and GRI need a ….
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 |
|---|---|
Recommended AD list provided to UC 4.0 end-users based on account industry information. | Percentage of users who view recommended ADs list. |
Recommended AD list provided to UC 4.0 end-users based on account affiliation information. | Percentage of users who view recommended ADs list. |
Recommended AD list provided to UC 4.0 end-users based on account state-agency information. | Percentage of users who view recommended ADs list. |
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 |
|---|---|---|
1 | Create report of recommended ADs based on account industry information. | Generate report of recommended ADs based on account industry information. |
2 | Create report of recommended ADs based on account affiliation information. | Generate report of recommended ADs based on account affiliation information. |
3 | Create report of recommended ADs based on account state-agency information. | Generate report of recommended ADs based on account state-agency information. |
4 | Deliver industry-based recommended AD list to end-users. | Percentage of users who view recommended AD list. |
5 | Deliver assoication-based recommended AD list to end-users. | Percentage of users who view recommended AD list. |
6 | Deliver state-agency-based recommended AD list to end-users. | Percentage of users who view recommended AD list. |
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
Internal Reporting
Power BI available reports for internal usage.
Note that updates are required in core to track the owner (called out on the Federated Data License PRD https://unifiedcompliance.atlassian.net/l/cp/4Wb1QpYn ) the Power BI data model to report and filter on Owner/Contributor and dependent upon data owner being tracked.
Requirement |
|---|
Description
Importance | Status | Comments | |
|---|---|---|---|
Following reports all pertain to shared lists which infers the organization is using the UCF APIs. | |||
Authority Document usage per organization | |||
List of companies and ADs they have placed in at least one shared list. | Done | Updates to core and BI model needed to filter by Contributor. | |
Authority Document count per organization. List of companies with a Cumulative count of ADs across all their shared lists. | Done | Updates to core and BI model needed to filter by Contributor. | |
Authority Document distinct / unique count per organization. List of companies with a Distinct count of ADs across all their shared lists. | Done | Updates to core and BI model needed to filter by Contributor. | |
Authority Document usage per Industry. Count of Authority Documents used in at least one shared list by Industry. | Done |
Updates to core and BI model needed to filter by Contributor.
Authority Document revenue tracking. | Done | Updates to core and BI model needed to filter by Contributor. | |
Authority document per country. Count of Authority Documents used in at least one shared list by Country. | Done | Updates to core and BI model needed to filter by Contributor. | |
Authority Document usage by Job Title and Job Function. Count of Authority Documents used in at least one shared list by Job Title and Job Function. | Done | Updates to core and BI model needed to filter by Contributor. | |
Authority Document usage by user. Count of Authority Documents used in at least one shared list by user. | Done | Updates to core and BI model needed to filter by Contributor. | |
Ability to filter all reports by data owner. In order to periodically distribute reports to data owners, need to update the data model and reporting to filter by data owner. | New | ||
Following reports all pertain builds. | |||
Build usage per organization. List of companies and ADs they have placed in at least one build. | |||
Build usage by industry. Count of Authority Documents used in at least one build by Industry. | |||
Build usage by annual revenue. | |||
Build usage by country | |||
. | |||
Build usage by user. Count of Authority Documents used in at least one build by |
Country. | |||
Compare build usage by organization. List of companies and Compare Builds they have created. |
In-product Reporting
Reporting functionality built into the UC 4.0 Platform.
Requirement |
|---|
Description
User Story
Importance | Status | Comments | |
|---|---|---|---|
Reports below all pertain to the contributor’s point of view. | |||
Ability for content creators to view and run reports from a content reporting page | |||
. | |||
All reports accessible through UI. | |||
All reports accessible via the API. | |||
Authority Document usage per organization. List of companies and ADs (owned by the contributor) they have placed in at least one shared list. | Can we share actual company name due to GRC concerns? | ||
Authority Document count per organization. List of companies with a Cumulative count of ADs (owned by the contributor) across all their shared lists own | |||
Authority Document distinct / unique count per organization. List of companies with a Distinct count of ADs (owned by the contributor) across all their shared lists. | |||
Authority Document usage per Industry. Count of Authority Documents (owned by the contributor) used in at least one shared list by Industry. | |||
Authority Document revenue tracking. | |||
Authority document per country. Count of Authority Documents (owned by the contributor) used in at least one shared list by Country. | |||
Authority Document usage by Job Title and Job Function. Count of Authority Documents (owned by the contributor) used in at least one shared list by Job Title and Job Function. | |||
Authority Document usage by user. Count of Authority Documents (owned by the contributor) used in at least one shared list by user. | Probably can’t distribute due to privacy policy. | ||
UC 4.0 Required Reports following similar requirements used for the Power BI reports. Following reports all pertain to | |||
builds. | |||
Build usage per organization. List of companies and ADs they have placed in at least one build. | |||
Build usage by industry. Count of Authority Documents used in at least one build by Industry. | |||
Build usage by annual revenue | |||
Build usage by country |
Count of Authority Documents used in at least one build by Country. | |||
Build usage by user |
Count of Authority Documents used in at least one build by user. | |||
Compare build usage by organization. List of companies and Compare Builds they have created. | |||
Below APIs and integrations related to key partner memberships (ISC2, ISACA …) | |||
API for Organization members Provide key partners (ISC2, ISACA …) with an API to return list of UC 4.0 Organizations who are members in their affiliation. | |||
API for User Members Provide key partners (ISC2, ISACA …) with an API to return list of UC 4.0 users who are members in their affiliation. | |||
Membership Verification UC 4.0 validates membership affiliation upon user registration as a member. | |||
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
Below is quick sketch of what a report dashboard might look like for a content contributor’s perspective.
The mockup is to show what is meant by a report as opposed to the proposed ADs after self-identification which is used accelerate the time-to-value of the AD selection process.
...
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.
...