Do not jump from story to framework
Before choosing screens, databases or programming languages, model the behavior the solution must support.
For attendance correction, identify the necessary information:
Teacher
Student
Class session
Attendance status
Original record time
Correction time
Correction reason
Translate rules into decisions
Business rule:
The assigned teacher may correct attendance during the 48 hours after the session. Every accepted correction must be recorded in history.
Pseudocode:
INPUT teacher, session, student, new_status, reason
IF teacher is not assigned to session
OUTPUT "Not authorized"
STOP
IF current time is later than session time plus 48 hours
OUTPUT "Correction period expired"
STOP
IF student is not enrolled in the class
OUTPUT "Student not found in this class"
STOP
SAVE old status in correction history
UPDATE attendance with new status and reason
OUTPUT "Attendance corrected"
No programming syntax is required. The algorithm exposes the decisions that future code must implement.
Validate with scenarios
Walk through the algorithm using concrete examples.
| Scenario | Expected result |
|---|---|
| Assigned teacher, correction after 3 hours | Correction accepted and recorded |
| Different teacher | Not authorized |
| Assigned teacher, correction after 60 hours | Correction period expired |
| Student from another class | Student not found in this class |
If a scenario has no clear result, the requirements or algorithm are incomplete.
Activity: design before implementation
Write pseudocode for this rule:
A student may register for a course only if places remain, prerequisites are completed and the registration deadline has not passed.
Test it with four scenarios, including one where multiple conditions fail.
INPUT student, course, current_date
IF current_date is after registration deadline
OUTPUT "Registration closed"
STOP
IF available places equal 0
OUTPUT "Course is full"
STOP
IF student has not completed every prerequisite
OUTPUT missing prerequisites
STOP
REGISTER student
REDUCE available places by 1
OUTPUT "Registration confirmed"
The order is a design decision. If the institution wants to show all problems at once, the algorithm should collect every failed condition before returning the result.
Course conclusion
You now have the foundation required before programming:
Understand the system
→ Think precisely
→ Discover the real need
→ Write verifiable requirements
→ Model rules and data
→ Design and test an algorithm
→ Translate it into code later
The next learning path can introduce programming as the translation of these already understood decisions into a language a computer can execute.
Continue learning
- IEEE Computer Society: SWEBOK provides the broader professional body of knowledge for software engineering. It is an advanced reference, not required reading for this beginner course.
What you learned
- Requirements reveal the data and decisions a solution must support.
- Business rules can be translated into conditions and ordered actions.
- Pseudocode makes behavior reviewable before choosing a language or framework.
- Concrete scenarios test whether the proposed logic handles normal and exceptional cases.
Knowledge check
- Why should the authorization check occur before updating attendance?
- What does a scenario without a clear expected result reveal?
- Must all correct algorithms check conditions in the same order?
- The system must reject an unauthorized action before it changes or exposes protected data.
- The requirement or algorithm contains an unresolved decision.
- No. Several orders may be correct, but the order affects which feedback appears first, efficiency and sometimes security. The choice should be intentional.