Capstone Brief: Requirements, Scope, and Success Criteria

Why Scope Comes Before Anything Else

The single most common reason capstone projects stall isn't lack of skill — it's an unscoped problem. "Build an AI assistant for my team" has no clear input, output, or finish line. A well-scoped project can be described in one or two sentences that name the specific input, the specific output, and the specific decision or action the workflow supports.

Signs a project isn't scoped yet:

• The problem statement uses words like "help with" or "improve" without naming a specific task
• There's no single example you could hand-simulate from input to output
• Success would be judged by a feeling ("it seems better") rather than a measurable criterion
• The project quietly keeps growing new requirements as you build

Choosing a Problem Worth Building

The strongest capstone projects come from a real, specific pain point — something from your own work, however small, where the current process is manual, repetitive, or inconsistent. A project built on a real problem naturally comes with real constraints (existing tools, real data formats, actual stakeholders) that make the design decisions from earlier modules concrete instead of abstract.

Writing Functional Requirements

Once a problem is chosen, functional requirements describe exactly what the system must do, stated concretely enough that you could hand them to someone else and they'd build the same thing:

1. What is the exact input format and source?
2. What is the exact output format and where does it go?
3. What decisions, if any, does the system make versus flag for a human?
4. What is explicitly out of scope for this version?

That fourth question matters as much as the first three — an explicit "not in scope" list is what keeps a capstone project finishable.

"A requirement you can't test isn't a requirement — it's a hope."

Defining Success Criteria You Can Actually Measure

Success criteria translate the project's goal into something checkable against the golden dataset and rubric built in a later step. Instead of "the system should give good answers," a measurable criterion looks like "at least 90% of golden dataset examples score 4 or higher on factual accuracy, and no example scores below 2 on instruction-following."

Identifying Constraints Early

Real projects have constraints — a rate limit on an API you plan to call, a data source that only updates daily, a stakeholder who needs a specific output format. Surfacing these during scoping, rather than discovering them mid-build, avoids redesigning core parts of the workflow late in the project.

Practical Review Checklist

Before moving from brief to build, confirm that you can:

• State your project's input and output in one or two concrete sentences
• List at least one explicit "out of scope" item for this version
• Point to a measurable success criterion, not a vague quality goal
• Name at least one real constraint (data, API, or stakeholder) you're designing around
• Describe one concrete example you could hand-simulate end to end

Conclusion

A clear brief — a specific problem, explicit requirements, a defined scope boundary, and measurable success criteria — is what turns "build an AI system" from an open-ended ambition into a project you can actually finish and evaluate.