Instructions to use this template:

Use this template to write the Product Requirements Document (PRD) for a single User JTBD or Initiative.
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.
Each section in the template has instructions, with examples explaining the type of content to be written in that section.
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.
Repeat from section <Use Case 1> Overview for every use case in the User JTBD or Initiative

Introduction

Many of the states working on ETB program have a lot of exiting content in the form of videos or pdfs. They prefer to reuse it for linking to the QR codes in their textbooks. This greatly reduces effort and time required in finding content for ETB. It also enables reuse of existing curated and quality content for ETB. This story details enabling of bulk upload of existing content by states through online portal.

JTBD

Use this section to elaborate on:

Jobs To Be Done: Uploading existing content one by one manually is an intensive effort and time taking. Hence they prefer bulk uploading of the content on to the system. Currently this is being supported by implementation team. However with 28 states on-boarding, and the bulk upload process happening in multiple iterations, it becomes a significant effort for implementation team to handle this. Hence there is a high value in enabling this process through online portal so that each state can do this through their resources. There is no requirement of a detailed review process for this content as it would have already happened. Hence review of this on system before publishing is only a formal verification.
User Personas: State resources who own the process of content pooling for ETBs are the primary users of this system. These are typically an identified set of teachers who collate existing content and map them to the state textbooks.
System or Environment: Desktops with Chrome browser and possibly MS office for working with excel. Network connectivity can be assumed but with lower bandwidth (1 mbps)

Requirement Specifications

Context:

In order to ensure effective scale rollout of ETB and associated programs across states, it is critical to make states self-reliant to execute most of the ETB activities themselves. One of the major activity for which state is dependent on Diksha implementation team is bulk content upload. In this PRD we are going explain process, workflow and upload format for bulk data upload on Diksha by states.

Actor: Content Reviewer

Detailed Process Flow:

Content reviewer access Diksha link
Reach out to Workspace. There should be a new option called: "Bulk Resource Upload". Under this, there will be two options:

Start Bulk Upload: To start bulk upload.
Bulk Upload Status: This should display the upload status of the last upload. For the first time when there is no previous bulk upload, this button would remain disabled or upon click should display a message "There is no previous bulk upload".

For new bulk upload, user should click on "Start Bulk Upload"
Download the sample upload file from the dialogue box appeared. Format of the bulk upload sheet is as follows: https://docs.google.com/spreadsheets/d/1zo_KVAU3y_RR3p4Gpgud-geROZYXv9Efpgwdflszemc/edit#gid=0
User should be able to access user guide form the dialogue box appeared (Refer wireframes).
User populates the bulk upload sheet in the required format.
Again select "Start Bulk Upload".
Select bulk upload type from the drop down. Permissible values are:

Create: Content created and sit in draft stage.
Create & Publish : Content created and published.
Create, Publish & Link to Textbook: Content created, published and linked to the respective textbooks as provided in bulk upload sheet.

Browse the populated bulk upload file. Click on "Upload".
In case file contains validation errors, error dialogue should appear with listed validation errors (Refer wireframes). User should rectify and upload again.
In case there is no validation error, upload should start and user should be redirected to Workspace screen.
While upload is in progress, "Start Bulk Upload" should be renamed to "Bulk Upload in Progress" and it should be disabled for next upload.
At the same time, clicking on "Bulk Upload Status", should take user to bulk upload status dialogue box, where user should see following fields:

Start Time
End Time
Total number of content
Content successfully processed
Content failed
Link to download status report "Download Status Report"

Status report would have following additional fields (apart from input bulk sheet fields) for each row (representing each content)

Upload Status: Success, Fail
Content Do_Id: If success, than do id of the created content
Reason of Failure: If fail, than reason of failure

Once upload is complete, "Bulk Upload in Progress" would again change to "Start Bulk Upload". Now user can start a new upload.
Till the new upload is started, "Bulk Upload Status" will show the status of previous upload.
User would be required to rectify the reason of failure and upload the failed content again.

Validations at the time of bulk sheet upload (Results in Validation Errors):

In case any mandatory column is missing, validation error should be thrown
Although "QR code" & "Textbook id" fields are not mandatory but in case user selects upload type as "Create, Publish & Link to Textbook", than these fields becomes mandatory and validation error should be thrown in case these columns are missing

Validations while processing each row for creating each content (Results in Content Failure):

Validation regarding mandatory fields should be checked while processing each row, in case cell value is missing fail that content
Validation regarding size and permissible data format should be checked for each field of each row, if not complied, fail the content creation

<Use Case 1> Overview

Replace the text within < > in the heading above with the name of the use case and provide a high-level overview of the use case for the JTBD or Initiative

<Use Case 1 Overall Process Workflow>

PRD > Bulk Upload of Content through CSV > Workflow.png

<Use Case 1 - User Story 1> Overview

Replace the text within < > in the heading above with the name of the use case and the name of the first user story. Provide a high-level overview of the user story here. Each user story is further elaborated in its sub-sections. The principles to bear in mind while writing a user story are: 1) it comprehensively captures a unique feature or functionality that a user can accomplish using the system 2) it encapsulates a single unit of functionality 3) it corresponds to one JIRA story 4) it is accomplished in one release. If, in a rare case, the functionality of a user story needs to be developed iteratively, the story should contain the Minimum Viable Product (MVP) content within the 'Main Scenario' section. All functionality to be developed in future releases, should be part of the 'For Future Release' section. Whenever the functionality is taken up for a release, it should become part of the 'Main Scenario' section. The 'Main Scenario' section should always be in sync with the current system functionality if the story is released. Scenarios detailed for the User Story are part of the acceptance criteria of the story.

<Main Scenario>

Replace the text within < > in the heading above with the name of the main scenario of the user story. Describe the typical usage scenario, as envisaged from a user perspective in a sequence of steps in the following table. As mentioned, the main scenario must necessarily cover the MVP and must always be in sync with the system functionality. To add or remove rows in the table, use the table functionality from the toolbar.

Srl. No.	User Action	Expected Result

<Alternate Scenario 1>

Replace the text within < > in the heading above with the name of the alternate scenario. Describe one or more alternate methods that a user can use to achieve the same functionality. Use the following table to elaborate on the alternate scenario. Repeat this section as many times as required for the number of alternate scenarios described.To add or remove rows in the table, use the table functionality from the toolbar.

Srl. No.	User Action	Expected Result

Exception Scenarios

Describe a list of exception scenarios in the following table and how they are handled. To add or remove rows in the table, use the table functionality from the toolbar.

Srl. No.	Error / Exception	Expected Handling

Wireframes

Attach wireframes of the UI, as developed by the UX team for screens required for this story

For Future Release

An optional section that describes functionality that may not be completed within a release

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.

<Use Case 1 - User Story 2> Overview

Repeat the entire Section and its corresponding subsections to elaborate the next user story in the use case. Repeat the section as many times as required.

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 Element	Description	Language(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

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 Name	Description	Purpose
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 Requirements	Load/Volume Requirements	Security / 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

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 Impacted	Impact Description
Specify the name of the product/solution on which this use case has an impact	Explain how the product/solution will be impacted.

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 Impacted	Impact Description
Specify whether existing users or data is impacted by this use case	Explain how the users/data will be impacted.

Key Metrics

Specify the key metrics that should be tracked to measure the effectiveness of this use case in the following table. To add or remove rows, use the table functionality from the toolbar

Srl. No.	Metric	Purpose of Metric
	Specify the metric to be tracked	Explain why this metric should be tracked. e.g. tracking this metric will show the scale at which the functionality is used, or tracing this metric will help measure learning effectiveness, etc.