School Requirements and Modules – Requirements Analysis | Lesson 3
Introduction
The principal of NexCoding Public School sends one sentence: "We need software to run the school." That is not enough to build anything.
In this lesson, you turn that sentence into clear requirements. You will decide who uses the system, what it must do, and how well it must do it.
By the end of this lesson, you will be able to:
- Explain the difference between functional and non-functional requirements.
- List the user roles of the SMS and what each one may do.
- Group requirements into modules.
- Write a user story with acceptance criteria.
- Decide what is in scope for this course and what is not.
Why this matters
Most failed projects do not fail because of bad code. They fail because the team built the wrong thing. A missing requirement found late is expensive: a new table, changed code, new screens, and fixed data.
The requirements you write today decide every table in Module 3 and every endpoint in Module 11. Ten minutes of clear thinking here saves days of rework later.
The concept
A requirement is one statement of what the system must do or how it must behave. Requirements come in two kinds.
A functional requirement describes a feature: something the system does. For example: "A teacher can mark daily attendance for her section."
A non-functional requirement describes a quality: how well the system does it. For example: "The class list loads in under 2 seconds."
Think of buying a car. "It has five seats" is functional; "it is safe and uses little fuel" is non-functional. You need both before you pay.
Example: functional vs non-functional
| Functional (what) | Non-functional (how well) |
|---|---|
| Record a fee payment and print a receipt | A payment is never saved twice, even if the user clicks twice |
| Enter exam marks for a subject | Marks are stored exactly; 72.5 never becomes 72.49 |
| Show the class list | The list loads in under 2 seconds |
| Parents see their child's report card | A parent can see only their own children |
A user story is a short requirement written from the user's point of view:
As a [role], I want [action], so that [benefit].
Acceptance criteria are the checks that prove a story is done. A common format is Given / When / Then: given a starting situation, when the user does something, then a certain result happens.
Apply it to the SMS
Here is the requirements document for NexCoding Public School, built step by step.
Example: the requirements document
Background: NexCoding Public School has Classes 1 to 10, with Sections A and B in each class and up to 40 students per section. Today, attendance is kept in registers, marks in spreadsheets, and fee receipts in a book.
Goal: one system for admissions, attendance, exams, and fees, usable from a browser and a mobile app.
Example: user roles
A role is a type of user with its own permissions.
| Role | Who | Can do |
|---|---|---|
| Admin | IT staff | Manage users, classes, sections, subjects, academic years |
| Principal | School head | See all data and reports |
| Teacher | Teaching staff | Mark attendance and enter marks for sections and subjects assigned to them |
| Accountant | Office staff | Create fee invoices and record payments |
| Parent | Guardians | See their own children's attendance, marks, and fees |
These five roles become rows in the Roles table in Module 3.
Example: modules and functional requirements
Each requirement gets an ID so everyone can refer to it in discussions and tests.
| Module | ID | Requirement |
|---|---|---|
| Masters | FR-MAS-01 | Admin creates academic years, classes, sections, and subjects |
| Students | FR-STU-01 | Admin admits a student with a unique admission number |
| Students | FR-STU-02 | A student can have more than one guardian; siblings can share guardians |
| Enrollment | FR-ENR-01 | Each year, a student is placed in one section with a roll number |
| Teachers | FR-TCH-01 | Admin assigns a teacher to a subject for a section and year |
| Teachers | FR-TCH-02 | Admin assigns one class teacher to each section every year |
| Attendance | FR-ATT-01 | A teacher marks each student Present, Absent, Late, or Leave for a day |
| Exams | FR-EXM-01 | Admin creates exams; each exam has subject papers with maximum marks |
| Exams | FR-EXM-02 | A teacher enters marks; marks cannot exceed the maximum; absent is recorded |
| Fees | FR-FEE-01 | Accountant creates invoices from the fee structure of the student's class |
| Fees | FR-FEE-02 | A payment gets a unique receipt number; part payments are allowed |
| Users | FR-USR-01 | Every user logs in; what they see depends on their role |
| Dashboard | FR-DSH-01 | The principal sees today's attendance percentage and fees collected |
Example: non-functional requirements
| ID | Requirement |
|---|---|
| NFR-01 | Class lists and report cards load in under 2 seconds for up to 10,000 students |
| NFR-02 | Passwords are never stored as plain text |
| NFR-03 | Deleted student records can be restored; nothing is lost by mistake |
| NFR-04 | Every change to marks and fees records who changed it and when |
| NFR-05 | Money and marks are stored as exact decimal numbers |
Notice how these rules shape the design. NFR-03 becomes "soft delete" and NFR-04 becomes "audit columns". You will build both in Module 3.
Example: a user story with acceptance criteria
Story ATT-01: As a class teacher, I want to mark attendance for my whole section in one screen, so that I finish it in the first five minutes of class.
Acceptance criteria:
- Given Anitha Rao is the class teacher of 10-A, when she opens attendance for today, then she sees every student enrolled in 10-A this year, ordered by roll number.
- Given she marks Kabir Singh as Absent and saves, when she reopens the screen, then Kabir shows as Absent.
- Given attendance for 10-A is already saved for today, when she saves again, then the existing records are updated, not duplicated.
- Given Anitha is not assigned to 10-B, when she opens attendance for 10-B, then she is refused.
Each criterion becomes a test later. Criterion 3 becomes a unique rule in the database in Module 3.
Example: scope of this course
Scope is the list of what will and will not be built. Writing down what is out of scope is just as important as what is in.
| In scope (this course) | Out of scope (later or never) |
|---|---|
| Everything in the module table above | Transport and bus routes |
| Library module (your homework project) | Hostel management |
| Timetable generation | |
| Online payment gateway (we record payments, we do not process cards) | |
| Websites and mobile screens (a later course part, after the backend) |
Common mistakes
- Writing vague requirements. "Attendance should be easy" cannot be tested. Fix: write something you can check, such as "a section of 40 in one screen".
- Forgetting non-functional requirements. Then speed and security become surprises at the end. Fix: ask "how fast, how safe, how many" for every module.
- No acceptance criteria. Developers and testers then disagree about "done". Fix: write Given / When / Then for every story.
- Not writing what is out of scope. The project then grows forever. Fix: keep an explicit out-of-scope list and agree on it with the client.
In real projects
The most expensive bug I have seen was not in code. A school client said "attendance" and the team built daily attendance. Two months later, we learned they needed attendance per period for senior classes.
The table design, the screens, and the reports all had to change.
Since then, I ask "show me how you do it today" before writing any story. Watch the register, the spreadsheet, the receipt book. Real workflows reveal requirements that nobody says out loud, such as part payments or a student with two guardians.
Best practices
- Give every requirement an ID and keep it testable.
- Write acceptance criteria before writing code.
- Record non-functional requirements with numbers: seconds, users, years.
- Keep an out-of-scope list and get the client to agree to it.
Recap
- Functional requirements say what the system does.
- Non-functional requirements say how well: speed, security, reliability.
- Roles decide who can do what.
- User stories follow "As a, I want, so that".
- Acceptance criteria use Given / When / Then and become tests.
- Scope lists what is in and what is out.
Homework
Library module task: Write three user stories for the Library module: issue a book, return a book, and charge a late fine. Give each story at least two acceptance criteria.
A correct result looks like: three "As a, I want, so that" stories, each with Given / When / Then criteria that you could test.
Show a sample solution
LIB-01: As a librarian, I want to issue a copy to a student, so that the library knows who has it.
- Given copy 2 of "Wings of Fire" is available, when I issue it to Aarav Sharma, then its status becomes Issued. The due date is 14 days from today.
- Given copy 2 is already issued, when I try to issue it again, then I am refused.
LIB-02: As a librarian, I want to record a returned copy, so that it can be issued again.
- Given copy 2 is issued to Aarav, when I record the return, then its status becomes Available.
- Given the copy is returned, then the return date is saved on the issue record.
LIB-03: As a librarian, I want late returns to get a fine, so that books come back on time.
- Given the due date was 3 days ago and the fine is 2 per day, when the copy is returned, then a fine of 6 is recorded.
- Given the copy is returned on or before the due date, then the fine is 0.
Quiz
Which of these is a non-functional requirement?
Show answer
Answer: B. The class list loads in under 2 seconds It describes how well the system works (speed), not a feature.
What is the correct user story format?
Show answer
Answer: B. As a, I want, so that User stories use As a, I want, so that; acceptance criteria use Given, When, Then.
Why does every requirement get an ID like FR-ATT-01?
Show answer
Answer: B. So people can refer to it in discussions and tests IDs make requirements easy to discuss, trace, and test.
Which requirement led to soft delete in the SMS?
Show answer
Answer: C. NFR-03 NFR-03 says deleted student records can be restored.
Why write an out-of-scope list?
Show answer
Answer: A. To stop the project from growing without agreement An agreed out-of-scope list keeps the project focused and avoids surprises.
Interview questions
Questions are grouped by experience level. Click a question to see a model answer. All questions: Architecture interview questions, Leadership interview questions, System Design interview questions.
Fresher (0-2 yrs)
F What is the difference between functional and non-functional requirements? concept
A functional requirement describes what the system does, such as "a teacher marks daily attendance". A non-functional requirement describes how well it does it: speed, security, reliability, such as "the class list loads in under 2 seconds". Both must be written down and testable.
F What is a user story? concept
A user story is a short requirement written from the user's point of view: "As a [role], I want [action], so that [benefit]". For example: "As a class teacher, I want to mark attendance for my whole section in one screen, so that I finish it in five minutes." It is completed with acceptance criteria that define when it is done.
F What is a role in requirements, and why do we list roles? concept
A role is a type of user with its own permissions, such as Teacher, Accountant, or Parent. Listing roles shows who uses each feature and what each must not be allowed to do. Roles later become rows in a Roles table and permission checks in the API.
Mid (3-5 yrs)
M What are acceptance criteria, and how do you write them? concept
Acceptance criteria are the checks that prove a story is done. A common format is Given / When / Then: given a starting situation, when the user acts, then a specific result happens. Each criterion should be testable, for example "given attendance for 10-A is already saved today, when the teacher saves again, then records are updated, not duplicated".
M How do requirements turn into database tables? design
The important nouns become tables (Student, Section, Exam), and their details become columns. Rules become constraints, such as a unique admission number or marks within the maximum. Relationships become foreign keys or junction tables, for example a student with two guardians. Non-functional requirements shape the design too, such as soft delete and audit columns.
M What do you do when a requirement is unclear? behavioral
Ask specific questions with examples instead of guessing, and where possible watch how the work is done today. Write down your assumptions and get them confirmed by the person who owns the requirement. A five-minute question is cheaper than a week of rework.
Senior (6-9 yrs)
S After the database is built, the principal says attendance must be taken per period, not per day. How do you handle it? scenario
First assess the impact: tables, API endpoints, screens, reports, and existing data that must be migrated. Then give an estimate and discuss priority and timeline with the client as a change request. Once agreed, update the requirements, the design, and the tests before changing code.
How to answer: Show a calm process: impact analysis, estimate, agreement, then change. Use the SMS detail: AttendanceRecords needs a period column and a new unique rule, and old daily records need a migration decision. Mention the trade-off between a quick patch and a clean redesign, and how asking "show me how you do it today" earlier would have caught it.
S How do you decide what is in scope and what is out of scope? behavioral
Rank features by business value, dependencies, risk, and the deadline, for example with Must, Should, Could, and Won't. Must-haves and their dependencies go in; the rest goes on a written out-of-scope list. The client agrees to that list, so new requests become planned changes instead of silent extra work.
How to answer: Explain the ranking method, then show the SMS example: payment gateways, transport, and timetables are out of Part 1 because the core school records come first. Close with the trade-off: a smaller scope delivered well beats a large one delivered late, and scope is revisited every release.
Architect / Lead (10+ yrs)
A Which non-functional requirements change when the SMS goes from one school to 1,000 schools? design
Data isolation becomes critical: one school must never see another's data. Load peaks multiply, for example every school taking attendance between 8 and 9 AM. Availability, backups and restore per school, deployments without downtime, security reviews, and the cost per school all become explicit requirements with numbers.
How to answer: List the categories (isolation, scalability, availability, recoverability, security, cost) and give one SMS number for each, such as "attendance save under 1 second at 8 AM for 1,000 schools". Then name the design consequence: a tenant column or database per school, caching, and horizontal scaling, and the trade-off between shared and separate databases (cost against isolation).
Resources
- Code for this lesson: git tag
lesson-3-school-requirements(code repository coming soon) - Video: coming soon
What's next
You know what to build. Next, install the tools you will use for the rest of the course and create the empty school database. Lesson 4: Tools setup
Want live sessions, code reviews, and interview preparation? Join the next batch at Sahasra Technologies.