To write software requirements for a final-year project, record where each need came from, express the intended behaviour or constraint clearly, and state how it will be checked. Keep proposed requirements distinguishable from confirmed ones. A feature list alone does not explain why the software needs those features.
Your report should connect the problem you investigated to the system you designed and the evidence you gathered. UniDraft helps organise your confirmed requirements, design material and actual evaluation findings into an editable project document. Start your software project write-up, then check the document against your records. You obtain the evidence and build and test the system; UniDraft does not perform those tasks.
What belongs in the requirements section?
Describe the intended users, system boundary, capabilities and relevant constraints. Your supervisor's brief determines whether these belong in a standalone software requirements specification, a methodology section or another arrangement. There is no single heading list that every Nigerian software project must use.
The IEEE Computer Society's requirements overview distinguishes functional capabilities from nonfunctional constraints and explains clear, verifiable, traceable requirements. Its industry examples are background, not performance targets or compulsory student headings.
Keep three records separate:
| Record | Question it answers |
|---|---|
| Requirement | What should the system do, or what condition should it meet? |
| Design decision | How do you propose to satisfy it? |
| Evaluation evidence | What actually happened when the implementation was checked? |
For example, needing to prevent overlapping bookings is different from choosing a database or proving that concurrent requests were handled correctly.
Build a source ledger before writing “users need”
Use only evidence you actually obtained with appropriate permission. Possible inputs include an authorised observation, a genuine consultation, a permitted document or an explicit project brief. A convenient assumption is not a reported interview finding.
Use this original working ledger:
| Field | What to record |
|---|---|
| Source ID and date | A stable reference to the actual evidence |
| Source type | Consultation, observation, document, brief or your own proposal |
| Relevant evidence | The actual need or issue, keeping quotation and interpretation separate |
| Permission and confidentiality | What you may retain, quote or show |
| Interpretation | What you think the evidence means for this system |
| Confirmation status | Confirmed, proposed or unresolved, with a real decision reference where available |
Protect personal information. A public report may use a suitable evidence code while the permitted supporting record stays securely stored. If access to intended users was unavailable, state that limitation; do not manufacture stakeholder validation. The ethics and consent guide helps plan appropriate evidence collection.
Turn a vague wish into separate requirements
Original fictional teaching exercise: a proposed campus equipment-booking system. No student interview, deployed service, institutional rule or successful test is claimed.
The starting sentence is “The system should be fast, secure and user friendly.” It leaves the actor, behaviour, conditions and evidence unclear. Break it into questions before choosing the final wording:
| Concern | Proposed wording or question | Still to confirm |
|---|---|---|
| Booking behaviour | A permitted student can request an available item for a specified period | Eligibility, availability rules and required request fields |
| Conflict handling | A request overlapping an existing booking for the same item is rejected | Whether touching time boundaries count as overlap; simultaneous requests |
| Access boundary | A student can view their own requests; other access follows explicitly defined roles | Real roles, exceptions and permitted data |
| Response time | Define the action, measurement point, test conditions and acceptable criterion | An agreed target and feasible measurement procedure |
| Usability | Define the relevant user task and evaluation criterion | Participants, permissions, procedure and interpretation limits |
These are proposed records, not stakeholder-approved requirements. Do not copy an arbitrary two-second target or call the system secure because it has a login screen. Resolve the context and verification method with appropriate advice.
Keep one requirement per reviewable record
Assign stable IDs so a changed sentence does not break every reference. Adapt this original worksheet to your brief:
| Field | Example entry type, not a completed requirement |
|---|---|
| Requirement ID and version | REQ-01, revision identifier |
| Source and need | Actual source ID; why this behaviour matters |
| Statement | Actor, action, conditions and observable outcome |
| Scope or exception | Where it applies and what remains outside it |
| Priority and rationale | Why it belongs in this deliverable rather than future work |
| Confirmation | Real decision, date and unresolved question; no invented approval |
| Planned verification | Relevant review, demonstration, test or evaluation reference |
| Dependent material | Design model, implementation reference and later evidence |
Read each statement aloud to someone familiar with the task. Ask what would count as meeting it and what would count as a failure. If the answers depend on unstated rules, the requirement still needs work.
Connect requirements to diagrams and tests
Follow one chain: source → requirement → design → implementation → check → evidence. A missing link is a question to resolve, not a blank to fill with a plausible claim.
Use the system-design diagram guide to choose the view that explains the relevant rule. A use-case diagram does not by itself specify every access or concurrency condition. Use the software test-case worksheet to define checks and record versioned executions. An expected result belongs to the plan; it becomes an observed result only after a real run.
For a quality requirement, choose evidence suited to the claim. A timed demonstration on one device cannot establish performance for every user. A usability evaluation answers defined user-task questions; it is not a complete security assessment. State what was not evaluated.
Record changes without rewriting project history
If a proposed requirement changes, keep its earlier version and record the reason. Identify affected diagrams, code and checks before claiming the updated documentation is consistent.
| Change record | What to retain |
|---|---|
| Request and reason | What changed and the actual supporting information |
| Affected IDs | Requirements, models and planned or completed checks |
| Decision and status | What was genuinely agreed, deferred or remains unresolved |
| New version | Where the revised requirement is recorded |
| Consequences | What must be updated or rechecked; remaining limitations |
Moving a feature to future work should be visible in the objectives, scope and evaluation account where relevant. Do not describe it as implemented merely because it appears in an older diagram.
Before submission or defence
- Every claimed stakeholder need has a traceable, permitted source, or is labelled as a proposal.
- Functional behaviours and quality constraints have clear conditions and planned verification.
- Priorities fit the actual objectives and available resources.
- Confirmation, implementation and successful evaluation are not conflated.
- Changes are reflected consistently in the requirement record, diagrams and evidence.
- You can explain one requirement's origin, design consequence, check and limitation.
When those records are ready, UniDraft can help turn the work you confirm into a written project for review. Start your project document and compare every requirement and evaluation claim with the underlying evidence before submission.
Source and scope
IEEE Computer Society: Software Requirements Specifications, read 25 October 2026, supports the requirements concepts used here. The ledgers and booking exercise are original teaching aids, not copied institutional templates or evidence of a completed project. Follow your supervisor's confirmed instructions for the actual report arrangement.