Complete Feature Walkthrough
Before you start
You need: all of Articles 01–06. This walkthrough uses every term the track introduced.
Time: 3–4 hours. It is written, not coded — the thinking is the work.
Goal
Take one School Management System feature from a vague business request all the way to production support, using every term this track has introduced, and produce a document a new team member could follow.
Assignment
The syllabus mini project is a student portal requirement breakdown. Do it on this request, received by the NexCoding Academy team:
From: Office administrator, NexCoding Academy
Subject: Finding students takes too long
We have 800 students. When a parent phones asking about their child,
I scroll through the list looking for the name. It takes several minutes
and the parent waits. Sometimes I open the wrong record because two
students have similar names.
Can we do something about this?
Produce eight deliverables, one per stage. Each is short — the value is in the thinking, not the length.
| # | Deliverable |
|---|---|
| 1 | A glossary in your own words |
| 2 | Clarification questions, and who you would ask |
| 3 | The epic / feature / story breakdown |
| 4 | One story with acceptance criteria |
| 5 | The layer-by-layer flow |
| 6 | The environment and lifecycle plan |
| 7 | Test scenarios and one defect report |
| 8 | The release and support plan |
Worked example: student search
This is one stage worked through, as a model for the other seven.
Stage 1 — the request arrives
The request describes a problem, not a solution. "Can we do something" is not a specification.
What is actually stated: 800 students, scrolling takes minutes, a parent is waiting, similar names cause wrong-record errors.
That last point is the hidden requirement. Search alone does not solve it — the results must show enough to distinguish two students called Priya. Roll number, class and section, at least.
Stage 2 — clarification
| Question | Ask |
|---|---|
| Search by name, roll number, or both? | BA / office administrator |
| Should transferred and graduated students appear? | Office administrator |
| Who is allowed to search? | Product Owner |
| Can staff of one school find another school's students? | Product Owner — security decision |
| How fast must it be? | Office administrator: "before the parent gets impatient" |
| How many results should show at once? | Office administrator |
| Is this in this sprint? | Product Owner |
| How will QA verify it? | QA engineer |
Four of these change the design. Asking takes ten minutes; guessing wrong costs three days.
The cross-school question is the one freshers do not think to ask, and it is the one with legal consequences.
Stage 3 — breakdown
Epic: Student Management
Feature: Student search
Story NCA-142: Search students by exact roll number
Story NCA-143: Search students by partial name
Story NCA-144: Show no-results and error states
Split by value, not by layer. NCA-142 alone already saves the office several minutes per call and could ship on its own.
Estimates: 3, 3 and 2 points. Sprint 14.
Stage 4 — the story
NCA-142 Search students by exact roll number
As an office administrator
I want to search for a student by their exact roll number
So that I can open the right record while a parent is on the phone
Acceptance criteria
1. Entering NCA-2024-0012 returns exactly that student
2. Results show name, roll number, class and section
3. Leading and trailing spaces are ignored
4. Search is case-insensitive
5. A roll number with no match shows "No students found"
6. Only students of the signed-in user's school are returned
7. Transferred and graduated students are excluded
8. Results appear within two seconds for 800 students
9. A user with the Student role receives 403
Out of scope
Partial name search (NCA-143), pagination, export
Criterion 2 addresses the similar-names problem from the original request. Criterion 6 is the security rule. Criterion 9 is authorisation. "Out of scope" prevents building NCA-143 by accident.
Stage 5 — the layers
Browser Search box; sends GET /api/students/search?query=... with the token
│ Trims input. Does NOT send schoolId.
▼
API Validates the query is not empty → 400 if it is
│ Reads schoolId from the token claim
│ Returns 200 with results, or 403 if the role is not permitted
▼
Service Trims, excludes inactive students, orders by roll number,
│ projects into a summary that omits ParentPhone
▼
Repository Parameterised query filtered by SchoolId and IsDeleted = 0
▼
Database Index on (SchoolId, RollNumber) so 800 rows return in milliseconds
Where each criterion is enforced:
| Criterion | Layer |
|---|---|
| 1, 5 | Repository — the query |
| 2 | Service — the projection |
| 3 | Service — trimming (the browser also trims, as a convenience) |
| 4 | Database — default collation |
| 6 | API reads the claim; repository filters |
| 7 | Service |
| 8 | Database — the index |
| 9 | API — [Authorize] |
Criteria 6 and 9 are enforced on the server only. Anything the browser does about them is convenience. A user with Postman bypasses every browser control, which is why the check must live where they cannot reach it.
Stage 6 — environments and lifecycle
Sprint 14, day 1 Planning; NCA-142 estimated at 3 points, moved to Ready
Day 2 Branch feature/142-student-search; In Progress
Day 3 PR #87 opened, referencing NCA-142; In Review
Day 3 Reviewed by Priya Sharma; one blocking comment on the
missing SchoolId filter; fixed and re-reviewed
Day 4 Merged; deployed to QA; In QA
Day 5 QA verifies all 9 criteria; raises one defect
Day 6 Defect fixed and reverified
Day 8 Deployed to UAT; the office administrator tries it
Day 10 Sprint review; demonstrated. Done
Next release Ships in v2.5.0
Environment differences that matter here:
| Environment | Students | Risk it hides |
|---|---|---|
| Development | 20 | Criterion 8 — two seconds — is meaningless at this size |
| QA | 800, including edge cases | Catches the performance and inactive-student issues |
| UAT | Production copy, anonymised | The administrator finds that results need the section shown |
| Production | 800 real records | — |
UAT is where the "show the section too" feedback arrives — validation, not verification. QA cannot produce it, because it is not in the criteria.
Stage 7 — testing
Twelve scenarios, one of which is the happy path:
| Scenario | Expected |
|---|---|
NCA-2024-0012, exists | That student, with class and section |
| Empty search | Validation message, no request sent |
NCA-9999-9999 | "No students found" |
" NCA-2024-0012 " | Found — spaces ignored |
nca-2024-0012 | Found — case-insensitive |
| A transferred student's roll number | Not found |
| A School 2 roll number, signed in as School 1 | Not found |
| Signed in as a Student role | 403 |
| 500-character input | Handled, no crash |
O'Brien in a name search | Found, no error |
| 800 students loaded | Under two seconds |
| Expired token | 401 |
A defect QA raises:
Title Search returns transferred students
Environment QA, build 2.5.0-rc1
Role priya.sharma@nca.test (Admin, School 1)
Steps 1. Open /students
2. Search NCA-2023-0044 (transferred in June)
Expected "No students found" — criterion 7
Actual The transferred student's record is displayed
Evidence Screenshot; SQL confirms Status = Transferred
Frequency Every time
Scope All transferred and graduated students
Since 2.5.0-rc1 — the feature is new
Severity Medium — wrong record could be opened during a call
"Expected" cites the criterion number. That removes any argument about whether it is a defect or a change request.
Stage 8 — release and support
Version v2.5.0 (MINOR — a backwards-compatible feature)
Migration CREATE NONCLUSTERED INDEX IX_Student_School_Roll
ON Student (SchoolId, RollNumber) INCLUDE (Name, ClassName, Section)
Additive; rollback is a DROP INDEX, no data loss
Deploy Wednesday 09:00; users notified Tuesday
Sequence Backup → migration → application → smoke test → monitor
Smoke test Sign in; search a known roll number; confirm class and section show;
confirm a School 2 roll number returns nothing
Monitor Error rate; search response time; 403 count
Rollback Deploy v2.4.1; the index can stay
Support Log searches that take over two seconds with a correlation id
The rollback is easy because the migration is additive. An index can be dropped with no data loss — which is why additive migrations are the rule.
Submission template
1. Glossary — your own words, no copying
Requirement: Feature:
Module: Bug:
Sprint: Release:
UAT: Production:
Endpoint: Payload:
2. Clarification
Question | Who you would ask | How the answer changes the design
(at least eight; mark the four that change the design)
3. Breakdown
Epic / Feature / Stories, with estimates
Why you split it this way rather than by layer
4. Story
As a / I want / So that
Acceptance criteria (at least eight, including empty, cross-school,
unauthorised, and one non-functional)
Out of scope
5. Layers
The five layers and what each does for this feature
A table mapping every criterion to the layer that enforces it
Which criteria are server-only, and why
6. Environments and lifecycle
Day-by-day sprint flow
Data differences per environment and the risk each hides
One thing you expect UAT to find that QA cannot
7. Testing
At least twelve scenarios
One defect report with every field, citing a criterion number
8. Release and support
Version number and why
Migration and its rollback
Deployment sequence, marking irreversible steps
Smoke test
What you would monitor
AI practice
Two AI exercises from this track's syllabus. Do both after the walkthrough is written, and apply Track 18's discipline — every answer is a hypothesis until you have checked it.
- Ask AI to quiz you on company terminology. Ask for one question at a time on the ten glossary terms, waiting for your answer before the next. Where you are wrong, write the correction in your own words rather than pasting the explanation.
- Ask for three examples of a user story, then evaluate them. Ask for three stories for the student search feature, then score each against this track's rules: is the role specific, or "as a user"? Is there a real "so that"? Are the criteria testable? Is there a criterion for the empty case, the cross-school case, the unauthorised case? Generated stories usually have none of the last three — and finding that is the exercise.
Track 18 — Context and prompting — covers giving a model the context it cannot infer.
Self-assessment
Your walkthrough is complete when someone joining the team could read it and understand the feature without asking you anything.
Five specific tests:
- Does every acceptance criterion map to a layer? A criterion nobody enforces is a criterion that will fail in production.
- Did you identify the cross-school criterion yourself? It is not in the original request. Nobody asked for it. It is the difference between a working feature and a data breach.
- Can you say which criteria are server-only? If your answer includes anything the browser enforces, reread Article 03.
- Are your test scenarios mostly not the happy path? One in twelve is about right. If half of yours are variations of "it works", you are testing what you built rather than what could break.
- Does your glossary use your own words? Copied definitions prove nothing. Being able to explain what UAT is, unprompted, is the point of the whole track.
Track completion criteria
You understand the terminology used in software companies, how a feature moves from requirement to release, and what each role is responsible for.
Specifically, you can:
- Name the roles on a software team and say what each is responsible for
- Describe how work reaches you, and ask a question someone can answer quickly
- Turn a business request into a user story with testable acceptance criteria
- Tell a bug from a change request
- Trace a request through all five application layers
- Explain why
schoolIdcomes from the token and not the request - Read HTTP methods, status codes and payloads correctly
- Distinguish authentication from authorisation
- Follow a feature through every lifecycle stage and environment
- Explain what moves between environments and what does not
- Design test scenarios covering boundaries, negatives and permissions
- Write a defect report a developer can act on
- Explain build, deployment and release as three different things
- Describe what happens first when production breaks
- Use the terms Requirement, Feature, Module, Bug, Sprint, Release, UAT, Production, Endpoint and Payload accurately
The syllabus recommends Track 03 — C# & .NET Programming Foundation or Track 13 — Python Programming Foundation next. Track 03 is the Microsoft path this curriculum follows.