Start With a Problem You Can Turn Into Requirements

"Make an app" is not a requirement.

A capstone needs a problem statement narrow enough to test.

Examples include a study-session tracker, fictional robotics match analyzer, invented inventory tool, tournament calculator, synthetic sensor analyzer, or command-line planning tool.

Do not use real student records, passwords, private identifiers, school operational systems, or data you do not have permission to process.

Concept flow

A capstone starts with testable requirements

A bounded problem becomes an implementation only after acceptance evidence is explicit.

1. PROBLEMdefine a narrow problem boundary
   identify
2. AUDIENCEstate who needs the result and why
   translate
3. REQUIREMENTSwrite observable functional expectations
   map
4. ACCEPTANCE EVIDENCEdefine tests or outputs that prove each requirement
   stress
5. EDGE STATESname invalid, empty, duplicate, and boundary cases

Define the audience

Write:

User/audience:
Problem they need solved:
What they do today:
What the program will improve:
What the program will not attempt:

A boundary prevents the project from becoming a vague everything-system.

Functional requirements must be testable

Weak: the app should manage scores well.

Testable: given a set of match results, the program calculates total points for each team and prints teams in descending score order.

A testable requirement has observable acceptance evidence.

Add a quality constraint

Functional requirements describe what behavior exists. A quality constraint describes an important property of the solution, such as deterministic calculations, visible invalid-record handling, or allowing a second formatter without changing scoring logic.

Do not invent enterprise-scale requirements without a credible reason or evidence plan.

Acceptance table

Create:

You need at least five functional requirements and one quality constraint. Each requirement must map to at least one validation case later.

Identify failure states early

For each input boundary ask about missing, malformed, duplicate, empty, or out-of-range data. For calculations ask about zero denominators, representation, empty results, and ties. For objects ask about invalid construction and mutation that could break invariants.

Do not wait for implementation to discover that the requirement never defined these cases.

Capstone requirement evidence

Submit the problem boundary, audience, requirements table, and at least three failure/edge states.

A reviewer should be able to design tests from this artifact without reading your source code yet.