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:
- 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?
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
- 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.