Product Requirements Document & IP Ethics

Week 2: Design Specifications & Ethics

Problem Identification

Draft a formal problem statement backed by statistical data, market research, or direct observation from affected stakeholders.

Stakeholders

• List every stakeholder your solution affects — end users, teachers/administrators, mentors, or anyone else with a stake in the outcome.
• For each, note what they’d want out of your solution and any concerns they might raise.

Design Criteria & Constraints

• Separate from your PRD’s quantified metrics, list your design criteria (what a good solution must do) and constraints (time, budget, tools, skills) and prioritize them — not everything can be a top priority.

Product Requirements Document (PRD)

Author a PRD defining strict, quantifiable target metrics, for example:

• System latency < 200ms
• Weight < 5 lbs
• Accuracy > 90%

Ethics & Intellectual Property

Conduct a patent and open-source license search (MIT, GPL, Apache) to ensure your proposed solution does not violate existing IP.

Peer Review (closes Week 2)

Trade your problem statement, literature review, and PRD draft with another team.

Problem Proposal Presentation

Close out Element C with a formal Problem Proposal: present your problem statement, justification evidence (Element A), similar solution matrix (Element B), stakeholders, and design criteria/constraints to your class or instructor.

• This is the checkpoint that greenlights moving into design work (Sprint 2) — treat it as a real proposal, not a status update.

• Incorporate peer-review feedback before presenting.

• Reviewers: check the problem statement is backed by evidence, the PRD metrics are quantifiable (not vague), and the literature review covers at least three prior-art sources with real limitations identified.
• Authors: log the feedback you received and note which points you’ll revise before presenting to your mentor in Week 3.

Need to update a submission later? Open the submissions dashboard.