Module 3: Capture Requirements

What You're Actually Building

Functional vs Non-Functional: What to Capture

It's useful to separate these. Functional = what the solution does. Non-functional = how it does it (performance, security, access, compliance). Both matter. Skip one and you'll hit surprises later.

Type	What to capture	Example
Functional	What the app or flow must do. Features. Behaviors.	"User can submit a request and see status within 24 hours." "Flow sends approval email when amount exceeds $500."
Non-functional	How it performs, who can access it, how it fits governance.	"Only HR can see PII." "Flow must complete within 5 minutes." "Must be audit-ready for SOC 2."

Leading a Requirement Capture Session

You don't need to be a professional facilitator. You need to ask good questions and write things down. Here's a simple structure.

Before the session

• [ ] You've invited the right people. Business owner, key users, maybe someone from governance if you know it touches sensitive data.
• [ ] You've sent a short agenda. "We're going to capture what this solution needs to do. Bring your questions and examples."
• [ ] You have a place to capture. Doc, OneNote, whiteboard—whatever your org uses.

During the session

• [ ] Start with the problem statement you wrote in Module 2. "We're solving X. Does that still sound right?"
• [ ] Ask: "What must this do?" List every "must." Be specific. "User can submit" vs "User can submit a request with attachments and receive a confirmation within 5 seconds."
• [ ] Ask: "Who can see what?" Access, privacy, compliance. This is where non-functional requirements show up.
• [ ] Ask: "What would break if we didn't have this?" Helps prioritize.
• [ ] Write it down in real time. Don't trust your memory. Read it back: "So I'm hearing that…"

After the session

• [ ] Organize what you captured into functional and non-functional.
• [ ] Send it back to the group. "Here's what I captured. Correct anything that's wrong. Add anything we missed."
• [ ] Get confirmation before you start building. "We're building to this. Yes?"

Discovery Questions (If You're Stuck)

Sometimes stakeholders say "we just need an app" without specifics. These questions help:

• Who does the first step today? What do they do? What do they need to see?
• What happens when something goes wrong? Who gets notified? Who fixes it?
• What data does this touch? Where does it live today? Who can access it?
• What would "done" look like? How would you measure success?
• Are there rules we have to follow? Compliance? Audit?

Requirement Capture Checklist

• [ ] You've run at least one requirement capture session with stakeholders.
• [ ] Functional requirements are documented. (What the solution does.)
• [ ] Non-functional requirements are documented. (Security, performance, access, compliance.)
• [ ] Requirements are confirmed and finalized with the business owner before build.

Next Step

With requirements in hand, move to Module 4: Design the Solution. That's where you decide data structure, app type, and where logic lives—all before you open the tool.