Course progress0%
Course content
2 to 4 hours

Final Project: Analyze Before You Code

Apply the complete course method to a real software need and produce a reviewable solution proposal.

By the end of this lesson

  • Investigate a real problem
  • Produce evidence-based requirements
  • Model rules and exceptional cases
  • Present a solution that can be reviewed before coding

Your mission

Choose one small, real process that currently creates delay, confusion or repeated manual work. Your goal is not to build an application. Your goal is to prove that you understand the problem well enough for a team to decide what should be built.

Possible subjects include:

  • booking a university room
  • tracking equipment loans
  • reporting a maintenance problem
  • registering for a workshop
  • managing tutoring appointments
  • following approval of an administrative request

Avoid choosing a solution such as “build an AI chatbot.” Start with a process and the people affected by it.

Step 1: Define the investigation

Write a short project statement containing:

Process being studied:
People affected:
Reason for investigating:
What is outside the scope:

Keep the scope small enough to understand in one week.

Step 2: Collect evidence

Interview or observe at least one person who performs the process. Ask them to show what happens today.

Record:

  • their goal
  • the current steps
  • information used at each step
  • delays and repeated work
  • common mistakes
  • rules and approvals
  • unusual situations
  • how they recognize success

Do not promise a feature during the interview.

Step 3: Separate need, problem and solution

Produce three statements:

  1. Need: the useful outcome people require
  2. Problem: the evidence-based obstacle they face
  3. Solution options: at least two possible responses

One option should be simpler than building a complete new application.

Step 4: Map the current workflow

Use a simple sequence:

Person or system
  ↓ action
Next person or system
  ↓ decision
Result

Mark every delay, duplicate entry, unclear responsibility and error point.

Step 5: Write the requirements

Your submission must include:

  • two user stories
  • at least four business rules
  • the essential data needed
  • two quality requirements
  • two constraints
  • three exceptional cases
  • acceptance criteria for one user story

Every requirement must be observable or verifiable.

Step 6: Model one important behavior

Choose one business rule and translate it into pseudocode.

Your algorithm must contain:

  • defined inputs
  • validation
  • at least one decision
  • an exceptional case
  • a clear output

Test the algorithm with one normal case and at least three edge cases.

Step 7: Review your own proposal

Before submitting, answer:

  • Which claim is supported by evidence?
  • Which point is still an assumption?
  • Which stakeholder has not been consulted?
  • What is the greatest risk in the proposed solution?
  • What could be removed to make the first version smaller?

Deliverable template

1. Context and scope
2. Stakeholders
3. Current workflow
4. Evidence and pain points
5. Need statement
6. Problem statement
7. Solution options and tradeoffs
8. User stories
9. Business rules
10. Data, quality requirements and constraints
11. Acceptance criteria
12. Pseudocode and test scenarios
13. Assumptions, risks and open questions

Evaluation rubric

Criterion Weight Strong evidence
Problem understanding 25% Need and problem are supported by observations
Requirements quality 25% Requirements are clear, consistent and testable
Solution reasoning 20% Options and tradeoffs are compared before selection
Algorithm quality 20% Logic handles normal, invalid and exceptional cases
Communication 10% The document is concise and understandable

Example of a weak submission

Students need a mobile application. I will use React Native, Node.js and MongoDB.

This chooses technologies without demonstrating the problem, users, rules, constraints or expected outcome.

Example of a stronger direction

Students currently wait outside the administration office to learn whether a document is ready. In five observed requests, three students returned more than once because status was unavailable remotely. The need is reliable status visibility. Possible solutions include automated email updates, a lightweight status page or integration with the existing student portal.

The second version uses evidence, states the need and keeps several solutions open.

Final self-check

  1. Can a reviewer understand the problem without seeing your proposed interface?
  2. Can every requirement be tested or verified?
  3. Does your algorithm explain what happens when information is missing or invalid?

If any answer is no, return to the corresponding course module. Analysis is complete only when another person can review your reasoning and identify what remains uncertain.

Lesson complete?

Your progress is saved on this device.