Design Sprint

Team Name : ____________________

Mentor Name : ____________________

Date of Submission : ____________________

Student Name: ___________________ Roll No: _______________Dept./

School___________

Student Name: ___________________ Roll No: _______________Dept./

School___________

Student Name: ___________________ Roll No: _______________Dept./

School___________

Student Name: ___________________ Roll No: _______________Dept./

School___________

Student Name: ___________________ Roll No: _______________Dept./

School___________

Student Name: ___________________ Roll No: _______________Dept./

School___________
Product Requirement Document (PRD)
Student teams must have successfully completed the FIH tool during their previous Innovation Sprints.
Teams that need to make updates or revisions to their existing FIH should rework the canvas accordingly
and resubmit it. Refer to the Innovation Sprint Workbook for detailed instructions on using the FIH tool.
From the completed FIH the teams can consolidate their PRD document.

1. Introduction

1.1 Purpose

“This section defines the main purpose of the product, its significance, and how it aligns with industry segments. Clearly state why the product is being
developed and the value it brings to the customer..”

1.2 Scope

“Outline what the product will and will not include. Clearly define the functionalities, features, and boundaries to set expectations among stakeholders.
Ensure that the scope aligns within objectives and constraints like budget, timeline, and technology feasibility. Give a detailed overview in terms of
primary functions and exclusion categories in terms of utilitarian level..”

1.3 Background & Motivation

“Explain the problem being addressed and the opportunity the product aims to capture. Provide context for why this solution is needed in the industry
scenario. Include relevant industry trends, pain points, and technological advancements driving the need for this product. Give a detailed overview in
terms of problem and opportunity..”

2. Product Overview

2.1 Product Features & Functionalities

“List the key features of the product, describing their importance and technical relevance. Each feature should have a brief description of its function,
the benefit it provides, and any dependencies or constraints associated with it..”

Features Functionalities Benefits Dependientes Description

# ## ### #### If needed

2.2 User Stories

“Define different user types and their specific needs. Explain how each feature of the product addresses the requirements of different user personas.
Use structured user story formats like..”

User Requirement Solution Provided

# ## ###

1
3. Technical Requirement

3.1 Performance Requirements

“Specify key performance metrics such as speed, accuracy, payload, and operational conditions,etc. Define the benchmarks that must be met for the
product to be considered successful.”

3.2 Hardware Requirements

“List all necessary physical components, including structural materials, actuators, sensors, and power requirements. Also specify design elements..”

3.3 Software Requirements

“Detail the software ecosystem, including firmware, communication protocols, and UI requirements. Specify necessary integrations and compatibility
with existing systems..”

4. Design Constraints
“Define physical, regulatory, and operational constraints. Ensure these limitations are well-documented to guide engineers and designers during
product development..”

5. Risks & Assumptions

5.1 Key Risks & Mitigations

“Identify potential risks in development, manufacturing, or market adoption. Currently surpassing the market adoption, but addressing it would make
much sense in defining the manufacturing techniques intact for design geomentries. Propose mitigation strategies to minimize project
vulnerabilities..”

Risk Mitigation Strategy Priority

# ## ###

5.2 Assumptions

“State key assumptions regarding market conditions, user behavior, and technological feasibility. Clearly documenting assumptions ensures alignment
with development phases..”

2
6. Roadmap & Timeline

6.1 Phases of Development

“Break down the development lifecycle into key phases. Briefly describe each phase’s objectives, expected outcomes, and critical deliverables..”

Phase Duration Key Deliverables

# ## ###

6.2 Development Milestones

“Define key milestones with estimated completion dates. This provides a structured timeline to track progress and manage expectations..”

Milestones
Milestone 1 - Ex: FIH Completion
Milestone 2 - Ex: Designing and POC Development
Milestone 3 - EX: MUP Development

Timelines

Milestone Day 0 Day 1 Day 2 Day 3 Day 4 Day 5

M1

M2

M3

7. Building Bill of Materials

Stage 1: Planning & Budgeting (Corresponds to Hackathon Day 0 / Phase 1)
The goal of this stage is to complete the left half of the template, focusing on the planned needs
and cost.

Step 1: Identify and Specify Components

● Columns to Fill: #, Components, Specifications.
● Action: Based on the Validated Design Brief (Phase 1 Deliverable), the team should list
every single component they think they will need. Be as detailed as possible.
○ Example: Not just "Microcontroller," but "Arduino Uno R3" or "Raspberry Pi Zero
W."
○ Example: Not just "Sensor," but "Ultrasonic Distance Sensor HC-SR04."

Step 2: Define Prototyping Expense Type (PET)

3
 ● Column to Fill: Prototyping Expense (PE) Type.
● Action: Classify each component using the provided dropdown options:
○ Reusable (Asset Cost): High-value, non-consumable items that will be returned or
retained for future projects (e.g., Raspberry Pi, specialized motor, power supply).
○ Consumable (Consumable Cost): Low-value, single-use, or items used up in the
build (e.g., wires, solder, glue sticks, 3D printing filament).
○ Asset: Likely the same as Reusable for the hackathon context. Confirm definitions
with organizers.

Step 3: Budget the Component Cost

● Columns to Fill: Unit Price (INR), Qty, Existing Inventory (Yes/No), Existing Inventory
Cost (INR).
● Action:
1. Determine the Unit Price and required Qty.
2. Check the available lab inventory. If the item is already available at the School/CoE,
mark Existing Inventory as Yes.
3. If the item is new, calculate the New Purchase Cost (INR) (Unit Price $\times$ Qty).
If it's existing inventory, note the original cost in Existing Inventory Cost (INR).

Step 4: Calculate the Budgeted Cost

● Columns to Calculate: Budgeted Expenses (Value) (INR), Asset Cost (INR), Reusable
Cost (INR), Consumable Cost (INR).
● Action:
○ Budgeted Expenses (Value): This is the total planned cost for this component (New
Purchase Cost + Existing Inventory Cost).
○ Breakdown (Asset/Reusable/Consumable): Distribute the Budgeted Expenses
(Value) into the appropriate column based on the PET type defined in Step 2.
○ Example: If a component is 'Reusable', its cost is entered under Reusable Cost
(INR).

Stage 2: Execution & Tracking (Corresponds to Hackathon Days 1–4 /

Phase 2–4)
The goal of this stage is to complete the right half of the template, focusing on the actual
utilization and money spent.

Step 5: Track Actual Component Acquisition

● Columns to Fill: The Breakdown of Actual Expenses section.
● Action: As the team builds their PoC (Phase 2) and MUP (Phase 4), they must track the
actual quantity and cost.
○ If a component budgeted for is not used, leave its actual cost fields blank.
○ If a component is used, ensure the actual cost is recorded. In a hackathon, this is
often the same as the budgeted cost unless a cheaper alternative was found.

Step 6: Calculate Actual Expenses

● Columns to Calculate: Actual Expenses (Cost) (INR).
● Action: Sum the actual costs used:
○ Actual Expenses (Cost) (INR): Calculate the total actual cost for the component
(Actual Asset Cost + Actual Reusable Cost + Actual Consumable Cost).

4
Step 7: Address Unexpected Purchases
● Columns to Fill: Components, Specifications, and the entire template row.
● Action: If a necessary component was not in the initial budget, add a new line to the
bottom of the template and fill out all columns (both Planned and Actual) for this new
purchase. Use the Remarks column to note that this was an unplanned component.

Stage 3: Review & Final Submission (Corresponds to Hackathon Day 4 /

Phase 4)
The goal is to finalize the totals and draw conclusions.

Step 8: Calculate Totals

● Row to Fill: Total row at the bottom.
● Action: Sum the values in the following columns:
○ Total Budgeted Expenses (Value)
○ Total Actual Expenses (Cost)
○ Total Asset Cost (Budgeted and Actual)
○ Total Reusable Cost (Budgeted and Actual)
○ Total Consumable Cost (Budgeted and Actual)

Step 9: Final Review and Remarks

● Column to Fill: Remarks.
● Action: For any significant discrepancy between Budgeted Expenses and Actual
Expenses, or for any critical component, the team should use the Remarks column to
explain:
○ E.g., "Used a borrowed motor (Existing Inventory) instead of purchasing a new
one, saving X amount."
○ E.g., "Component failed during Phase 3 testing and required a replacement
purchase."

5
BoM Template

6
8. Appendix & References
“Include additional resources, component datasheets (Tech spec sheet for module, component and attributes level), regulatory documents (compliance testing standards), and market research references
(adoption analysis for the existing product). This helps future users validate and expand upon the project details..”