Lesson Overview
Turn a vague brief into functional requirements, constraints, user stories and acceptance checks.
Portfolio focus: Choose a small app idea and write five requirements.
Starter: think before typing
Before running this requirements analysis example, find the line where the main idea becomes active. Write a prediction: what must already be true for that line to work, and what should be different after it runs? The checked run ends with `As a learner, I want feedback, so that I can improve. Testable story: true`; predict how the focus line helps produce that evidence.
Learning Objectives
- Separate functional requirements from constraints.
- Write useful user stories for a small program.
- Create acceptance criteria that can be tested.
- Avoid adding hidden assumptions to a brief.
Learning Outcomes
- By the end of the lesson, you can separate functional requirements from constraints.
- By the end of the lesson, you can write useful user stories for a small program.
- By the end of the lesson, you can create acceptance criteria that can be tested.
- By the end of the lesson, you can avoid adding hidden assumptions to a brief.
Why this idea exists
Requirements work exists because many software failures begin before code is written. Early programmers often worked close to the machine, but as software entered business, science, government and public life, the harder question became: are we building the right thing?
User stories became popular through agile methods because they keep attention on people, goals and value. They are not a replacement for precise requirements; they are a way to stop technical work drifting away from the user problem.
At degree level, requirements should be treated as testable claims. If a requirement cannot be checked, it is probably still too vague, and vague requirements usually become vague code.
Deep dive
Mechanism in this example
The important mechanism is visible around `boolean hasReason = story.contains("so that");`. Read it as a concrete move in the program, not as decorative syntax: identify what value, object, branch, call or boundary is being created at that point.
Design pressure
At degree level, requirements should be treated as testable claims. If a requirement cannot be checked, it is probably still too vague, and vague requirements usually become vague code.
Failure mode to watch
For Requirements and User Stories, deliberately disturb the assumption behind `boolean hasReason = story.contains("so that");`: use an awkward value, missing input, wrong order of calls or boundary case. The useful question is how that disturbance exposes a weakness in the requirements analysis design.
Extension step
Extend the example by doing this: Convert three requirements into user stories. The point is to make one small change that forces you to revisit the concept, rather than adding unrelated features.
Portfolio standard
The portfolio note should not repeat the lesson wording. It should show the edited code, the run result, and your own explanation of this evidence: write one acceptance test for each user story.
Lesson visual
Type this and run it
Create RequirementsAndUserStoriesDemo.java, type the program, and run it before changing anything. This section is about reproducing the checked baseline.
public class RequirementsAndUserStoriesDemo {
public static void main(String[] args) {
String story = "As a learner, I want feedback, so that I can improve.";
boolean hasUser = story.contains("As a");
boolean hasGoal = story.contains("I want");
boolean hasReason = story.contains("so that");
System.out.println(story);
System.out.println("Testable story: " + (hasUser && hasGoal && hasReason));
}
}Build and run it with:
javac RequirementsAndUserStoriesDemo.java && java RequirementsAndUserStoriesDemoExpected baseline: As a learner, I want feedback, so that I can improve.
Testable story: true
Run the code in your browser
Use the editor as an experiment surface. First run the checked version, then make one small change to the part of the program that demonstrates requirements analysis and compare the new behaviour with the reference output.
As a learner, I want feedback, so that I can improve.
Testable story: trueLine-by-line explanation
Read the code as a sequence of responsibilities. The focus line for this lesson is boolean hasReason = story.contains("so that");; the surrounding lines prepare it, use its result or make the behaviour observable.
public class RequirementsAndUserStoriesDemo {This names the runnable class for the Requirements and User Stories example, giving the compiler and JVM one clear unit to build.
public static void main(String[] args) {This is the program entry point. In Requirements and User Stories, it keeps the demonstration of requirements analysis in one traceable starting script.
String story = "As a learner, I want feedback, so that I can improve.";This introduces story as named state for Requirements and User Stories. Later lines can read, update, pass or print that specific value as evidence.
boolean hasUser = story.contains("As a");This introduces hasUser as named state for Requirements and User Stories. Later lines can read, update, pass or print that specific value as evidence.
boolean hasGoal = story.contains("I want");This introduces hasGoal as named state for Requirements and User Stories. Later lines can read, update, pass or print that specific value as evidence.
boolean hasReason = story.contains("so that");This introduces hasReason as named state for Requirements and User Stories. Later lines can read, update, pass or print that specific value as evidence.
System.out.println(story);This prints story as the observable evidence for Requirements and User Stories. The output lets the learner check whether the requirements analysis idea behaved as predicted.
System.out.println("Testable story: " + (hasUser && hasGoal && hasReason));This prints "Testable story: " + (hasUser && hasGoal && hasReason) as the observable evidence for Requirements and User Stories. The output lets the learner check whether the requirements analysis idea behaved as predicted.
}This closes the innermost Requirements and User Stories block, so the immediately preceding method, branch or loop has finished.
}This closes the outer Requirements and User Stories structure, returning the reader to the surrounding class or file.
Worked example
From code to explanation
Problem: Use Requirements and User Stories to complete a small portfolio-quality step: Choose a small app idea and write five requirements.
Method: Locate the line `boolean hasReason = story.contains("so that");`, explain the exact role it plays, then decide what you would change to extend the example without changing the whole program.
Reveal worked answer
The checked run should produce `As a learner, I want feedback, so that I can improve. Testable story: true`. A strong answer links the result back to requirements analysis: what was created, selected, stored, called or protected, and why that matters for the portfolio task.
Trace the program
Before: Before the key operation, identify the relevant value, object, branch or resource that the requirements analysis concept depends on.
During: Trace `boolean hasReason = story.contains("so that");` as the Requirements and User Stories example executes. Say whether that operation creates data, checks a condition, calls behaviour, stores information or crosses a boundary.
After: Compare the run with the expected evidence: `As a learner, I want feedback, so that I can improve. Testable story: true`.
Change: Now convert three requirements into user stories, run again, and explain the smallest reason the behaviour changed.
Common misconception
A common mistake in requirements and user stories is treating the example as a finished answer. For requirements analysis, the important question is narrower: which operation carries the idea, what does it make possible, and what would break if you changed it carelessly?
Quick checks
1. In this Requirements and User Stories example, what is the best reason to focus on `boolean hasReason = story.contains("so that");`?
2. Which evidence is strongest after you edit and rerun this example?
How to study this lesson
For Requirements and User Stories, predict how requirements analysis changes the run before you press Run.
Use the first portfolio task as your main edit: Choose a small app idea and write five requirements.
Use the second task as your variation: Convert three requirements into user stories.
Finish with evidence, not a diary entry: Write one acceptance test for each user story.
Portfolio Practice
- Choose a small app idea and write five requirements.
- Convert three requirements into user stories.
- Write one acceptance test for each user story.
Final self-check
Can you explain the key operation?
Explain the line identified in the quick check in one or two sentences. Your answer should say what it does before the output As a learner, I want feedback, so that I can improve.
Testable story: true appears.
Can you justify the portfolio evidence?
Your evidence should include the original run, one edited run, and a short note explaining how the edit affected requirements analysis.
Study route
Practise requirements analysis by predicting the Java example, typing it, running it in the browser, tracing the result and saving portfolio evidence.
Next, move into Program Design Before Java and carry forward one improvement from this lesson into the next program.