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
For a real-process investigation, interview or observe at least one person who performs it. Ask them to show what happens today. If access is unavailable, use a clearly labelled fictional scenario: state its assumptions and prepare an interview plan. This alternative practices analysis but does not count as validated user research.
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:
- Need: the useful outcome people require
- Problem: the evidence-based obstacle they face
- 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?
Step 8: Show how your reasoning changed
Keep a short decision journal alongside your proposal:
| Initial belief | Evidence or question | Revised decision | What remains uncertain |
|---|---|---|---|
| A reminder will prevent missed collections | Some customers say they cannot collect during opening hours | Investigate collection arrangements before choosing reminders | How often does each cause occur? |
The row above is an illustrative example. Use your own evidence; do not invent interviews, measurements or client experience. If you work alone on a fictional scenario, label its facts as exercise assumptions and list what you would verify in reality.
Include the following in your submission:
- Separate at least two supported facts from two assumptions.
- Explain one question that changed your understanding, or identify a question whose answer could change it.
- Compare two solutions against the same constraints, including a simple option.
- Find a counterexample to your first rule or algorithm and show the revision.
- Introduce one clearly labeled hypothetical change, such as a shorter deadline. Identify affected decisions and repeat both changed and unchanged scenarios.
- State what evidence would make you reconsider your chosen solution.
Review the quality of the reasoning
A strong submission connects claims to evidence, leaves unresolved decisions visible and explains alternatives fairly. A weak submission presents guesses as facts or chooses examples only because they confirm its preferred answer.
There may be several acceptable solutions. Judge them against the stated need and constraints. Explaining why you revised an answer is more valuable than pretending your first answer was complete.
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
14. Decision journal, counterexample and change review
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 are compared; assumptions, counterexamples and revisions are explained |
| 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.
This illustrative second version shows how evidence could support a need while keeping several solutions open. Its numbers are fictional teaching examples; your own submission must distinguish actual observations from assumptions.
Final self-check
- Can a reviewer understand the problem without seeing your proposed interface?
- Can every requirement be tested or verified?
- 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.
Continue to implementation
When you can explain your inputs, rules, exceptions and expected outcomes, continue to Course 02. Keep this decision journal as your method. Course 02 uses shared small exercises so everyone can compare expected results; it does not require building your chosen investigation as an application. You will transfer the reasoning, then build a tested order program that Course 03 extends.