Instructions to use this template:

  1. Use this template to write the Product Requirements Document (PRD) for a single User JTBD or Initiative. 
  2. Each workflow within the PRD will correspond to an Epic in JIRA. Each User Story will correspond to a Story in JIRA that will be part of the Epic.
  3. Each section in the template has instructions, with examples explaining the type of content to be written in that section. 
  4. You may start typing into the section by eliminating the instructional text, or delete the instructional text after you have entered all content for the section.
  5. Repeat from section <Use Case 1> Overview for every use case in the User JTBD or Initiative

Introduction

This report provides details of Diksha usage in terms of QR code Scans and Unique devices for each district of a state. All the graphs show the usage status per month. This report is updated on date 1st of every month. The data and dashboards are state specific.

JTBD

Use this section  to elaborate on:

  • Jobs To Be Done: As a state admin, the performance of each district of the state such as consumption, failures in ETB on a monthly basis should be monitored.
  • User Personas: The logged-in users who have State Admin role, report viewer role can access this report.
  • System or Environment: works on for desktops with Chrome browser only.

District-wise Report over time

Description:

This graph provides overall consumption data on a weekly basis (i.e; from Monday to Sunday ) over a period of one year and should be generated every Monday  for that state.

Details: In this report, we will be displaying the total QR scans data (portal + app) on a weekly for that state. This data is calculated by the district wise. 

  • This report provides 3 consumption datasets
    • Total no of QR Code Scans
    • Unique devices in that district for that state. 
    • Total no of content plays
  • For each dataset, the Graph should be created and it should have districtwise filter option.
  • This report should be calculated over a period of time.
  • If no district is selected in the filter, Overall data should be displayed.
  • This data is calculated based on the device location data.


Graph:

  Graph description:

  • X-axis with Date of data updated and in Y-axis with a total count.
  • Whenever the users go on to the graph, they will be able to see overall data of the state. District wise filter should be enabled and the user should be able to get the data by filtering the district name whenever needed. 
  • All the district values should be shown in the dropdown.

Table:

District Name\WeekWeek 1
Unique DevicesTotal QR Code Scans

Total no of content plays

APPPortalTotalAPPPortalTotalAPPPortalTotalUpdated on
District 11000471047678106881000050010500 
Unknown16786717425894062920000500025000 












Week 2
District 11000471047678106881000050010500 
Unknown16786717425894062920000500025000 

Table description:

District Name: All the districts in the state should be shown.

Unique Devices: Total no of unique devices opened Diksha in that district from that state   

Logic

  • APP: Total no of unique devices used Diksha APP in that week from that district in that state.
  • Portal: Total no of unique devices used Diksha portal on the web (i.e; in Desktop and mobile web) in that week from that district in that state. 
  • Total: APP + Portal

Total no of QR code scans: Total no of QR code scans which include both APP and portal.

Logic

  • APP: Total no of  QR code scans (from Diksha or different app) from those unique devices of that week from that district in that state.
  • Portal: Total no of  QR code scans from those devices in GET page (i.e; in Desktop and mobile web) in that week from that district in that state. 
  • Total: APP + Portal

NOTE: Total scans include both Successful scans, Failed scans, and Unlisted scans.

Total no of content plays: Total no of content plays which include both APP and portal.

Logic

  • APP: Total no of content plays from those unique devices in that week from that district in that state.
  • Portal: Total no of  content plays from those unique devices  (i.e; in Desktop and mobile web) in that week from that district in that state. 
  • Total: APP + Portal

Updated on: The date when the data got updated 


Points to be considered

  • In this table, each week data should be added next to the previous week data and so on.
  • In case, If there is no mapping available for any of the city to the district, the district cell will display as "Unknown". However corresponding data will be shown in week cell.
  • Each district unique devices count is captured on a weekly basis for that state. This is for overtime and all the districts of that state are shown in the table and in the graph as well.


JIRA Ticket ID

Insert the JIRA Ticket ID created for this story here. Click the + sign on the toolbar, select JIRA Issue/Filter from the list and either select a JIRA issue from the list or create one.   

Localization Requirements

Use this section to provide requirements to localize static content and/or design elements that are part of the UI in the following table. Localization of either the framework, content or search elements should be elaborated as a user story. To add or remove rows in the table, use the table functionality from the toolbar.   

UI ElementDescriptionLanguage(s)/ Locales Required
Mention the UI Element that requires localization. e.g. Label, Button, Message, etc. Provide the exact details of the element that requires localization. e.g. User ID, Submit, 'The content is currently unavailable' Mention all the languages or locales for which localization is required
NANANA


Telemetry Requirements

Use this section to provide requirements of the events for which telemetry should be captured. To add or remove rows in the table, use the table functionality from the toolbar.   

Event NameDescriptionPurpose
Mention the event that will generate telemetry and which needs to be captured. Provide event details. e.g. clicking upload for textbook taxonomy Provide a reason why the event telemetry should be captured.


Non-Functional Requirements

Use this section to capture non-functional requirements in the following table. To add or remove rows in the table, use the table functionality from the toolbar.   

Performance / Responsiveness RequirementsLoad/Volume RequirementsSecurity / Privacy Requirements
Provide the perfomance or the responsivenes required from the system to ensure that the Use Case is effective. Provide the load or volume required from the system to ensure that the Use Case is effective.Provide security and privacy requirements for an effective Use Case
NANANA


Impact on other Products/Solutions

Use this section to capture the impact of this use case on other products, solutions. To add or remove rows in the table, use the table functionality from the toolbar.   

Product/Solution ImpactedImpact Description
Specify the name of the product/solution on which this use case has an impact Explain how the product/solution will be impacted.
NANA


Impact on Existing Users/Data 

Use this section to capture the impact of this use case on existing users or data. To add or remove rows in the table, use the table functionality from the toolbar.   

User/Data ImpactedImpact Description
Specify whether existing users or data is impacted by this use case Explain how the users/data will be impacted.



Key Metrics