Lab 3: Requirements Elicitation¶

What you will learn¶

• How to choose a problem worth building a system for, using evidence rather than enthusiasm
• How to run a problem interview that gets facts, not compliments
• How to turn interview notes into requirements: a job statement, a persona, a journey map, the riskiest assumption, and an MVP scope
• How to use an AI to help synthesize notes without letting it invent findings

Requirements elicitation is the part of the SDLC that agents cannot do for you. An agent has never met your user. Everything it knows about them comes from what you write down today.

Part A: Choose your project's user (10 minutes)¶

Open the problem discovery worksheet in Excel or Google Sheets. Each row is a life domain with everyday activities. For three rows, fill in:

• Who: a real person you can talk to this week (yourself counts as one)
• Frustration: something specific that goes wrong for them, in their words if you know them
• Job to be done: "When I'm ___, I want to ___, so I can ___"
• The 1 to 5 scores for Frequency, Intensity, and Willingness to Pay, and the 0/1 columns

Pick the row with the strongest evidence and the user you can actually reach (the Access Test). That is your project candidate. Save the sheet as labs/lab-03/worksheet.csv.

Part B: Practice interview in pairs (20 minutes)¶

Pair with a classmate. Each of you interviews the other for eight minutes about a recurring problem in their life (it does not have to be your project). Then switch.

Rules, from The Mom Test:

• Ask about the past, not the future. "Walk me through the last time this happened" beats "Would you use an app that...?"
• Do not describe your idea. If you catch yourself pitching, stop.
• Ask what they do now, what it costs them, and what they have already tried.
• Write down exact phrases they use. Those words become your interface labels later.

Interviewer's question bank (pick five):

1. Tell me about the last time you dealt with ___. What happened, step by step?
2. What was the hardest part?
3. How often does this happen?
4. What do you do about it now? What tools, spreadsheets, or people are involved?
5. What have you tried that did not work?
6. How much time or money does it cost you?
7. Who else is involved or affected?
8. If you could wave a wand, what would be different? (Then ask why.)

Take notes in labs/lab-03/practice-interview.md. Use initials, not names.

After both interviews, mark each line of your notes with the rung of the Evidence Ladder it reaches: said (an opinion or prediction), did (something they actually did), or paid (something they spent money, time, or reputation on). Count each kind.

Part C: Synthesize with an AI, carefully (15 minutes)¶

Start Claude Code in your course repo and paste your notes with this prompt:

Here are my notes from a problem interview (names removed). Do not add anything
that is not in the notes.

1. List every distinct problem or pain mentioned, each with the exact quote that
   supports it.
2. Classify each as said, did, or paid on the evidence ladder.
3. Write one job-to-be-done statement: When I'm ___, I want to ___, so I can ___.
4. List what the person does today instead (the current habit), and what it costs them.
5. List three questions I should have asked and did not.

Save it as labs/lab-03/synthesis.md.

Check it against your notes. Strike out anything the AI wrote that is not supported by a quote. Write how many items you removed at the top of the file.

Part D: Draft your project requirements (rest of class, then after)¶

Before Thursday, interview at least two real users or stakeholders for your project (Sprint 1 requires three by Nov 23). Put notes, with names removed, in discovery/interview-1.md, discovery/interview-2.md, and so on.

Then draft discovery/requirements.md in your course repo from this template. Every claim should point to an interview.

# Requirements: <system name>

## Problem statement
<One paragraph: who, what goes wrong, how often, what it costs them. Cite interviews.>

## Job to be done
When I'm ___, I want to ___, so I can ___.

## Users and stakeholders
| Role | Who (initials or title) | What they need from the system |
|---|---|---|
| Primary user | | |
| Stakeholder (pays, approves, or is affected) | | |

**Not for:** <who this system is deliberately not designed for>

## Persona
<Name, role, context, goals, frustrations, current tools. One short paragraph.>

## Current process (as-is)
<Numbered steps of how the job gets done today, including spreadsheets, emails, and workarounds.>

## Journey map
<A Mermaid journey diagram; see the example below.>

## Functional requirements
| ID | The system shall... | Priority (Must / Should / Could / Won't) | Source |
|---|---|---|---|
| FR-1 | | Must | Interview 1 |

## Non-functional requirements
| ID | Category (usability, security, performance, privacy, cost) | Requirement | Source |
|---|---|---|---|
| NFR-1 | Privacy | | |

## Riskiest assumption
<The belief that, if false, makes the system pointless. How you will test it.>

## MVP scope
**In:** <the Must items only>
**Out:** <everything else, and why>

A journey map in Mermaid, which GitHub renders automatically:

```mermaid
journey
  title Club treasurer collecting dues
  section Before the meeting
    Export Venmo statement: 2: Treasurer
    Open last year's spreadsheet: 3: Treasurer
  section Matching payments
    Match each payment to a member: 1: Treasurer
    Message members who have not paid: 2: Treasurer
  section Reporting
    Send totals to the club president: 4: Treasurer, President
```

The numbers are the user's mood at each step, 1 (bad) to 5 (good). The lowest scores are where your system should help.

Reflection¶

Write labs/lab-03/reflection.md:

1. How many of your practice-interview notes were said, did, and paid? What does the mix tell you about how much to trust them?
2. What did the AI synthesis get wrong or invent, and how did you catch it?
3. What is your project's riskiest assumption, and what is the smallest thing you could do this week to test it?

Turn in¶

Submit the link to labs/lab-03/ on Canvas. Check that your repo contains:

• labs/lab-03/worksheet.csv, practice-interview.md (with ladder marks), synthesis.md (checked), reflection.md
• At least two discovery/interview-N.md files, names removed
• A first draft of discovery/requirements.md

How larger systems do this¶

On a large project, requirements elicitation is a team effort that can take months: stakeholder interviews, workshops (often called JAD sessions), observation of people doing the work, document analysis, and surveys, all tracked in a requirements management tool with an ID for every requirement so it can be traced to a design element and a test. You just did a small version of each step. The traceability you started with the Source column and the FR and NFR IDs is the same idea: in Lab 4 those IDs will appear in your user stories, and in Lab 7 in your tests.