Instructional Problem & Requirements Analysis

Week 1: Instructional Problem & Requirements Analysis

Answer and draft the following sections for your team’s engineering portfolio (sample Table of Contents structure):

• Instructional Problem — What problem are you solving, and for whom?
• Current State — Introductory KSAs — What do learners/users know and do today?
• Desired State — Post-Onboarding KSAs — What should they know and do after your solution?
• Gap Between Current and Desired States — What’s missing?
• Instructional Expectations — What outcomes should your solution guarantee?
• Research Topic — What are you studying, specifically?
• Research Topic Importance — Why does this matter?
• Research Questions
  • RQ1 — Learner/User Experience
  • RQ2 — Support and Progress
• Research Purpose — What will answering these questions accomplish?

Justification Evidence

A problem statement is only as strong as its evidence. Gather all three of the following before finalizing your problem statement — this is what “Justification” means for Element A, and it’s the piece most teams skip:

• Expert Interviews — Talk to at least one person with real expertise or experience in the problem space (a teacher, industry professional, or someone directly affected). Record who you talked to and what they told you.
• Consumer / Stakeholder Surveys — Run a short survey of the people who would actually use or be affected by your solution. Even 10-15 responses is enough to surface real signal.
• Scholarly Articles — Cite research (not just blog posts) that backs up why this problem matters and what’s already known about it.

Team Norms & Roles

• Establish team norms and allocate individual technical ownership roles.
• Conduct an initial requirements-gathering interview with an industry mentor.

Hardware Innovation

Consider whether adding a hardware component strengthens your solution (e.g. sensors, GPUs, embedded devices).