FYP documentation: SRS, diagrams and the final report
Final year project documentation is the record of what you built: a software requirements specification, the design diagrams, the test cases and results, and the report that ties them together. It is usually sixty to a hundred pages, and it is where most groups lose marks they had already earned in the code.
Your department handbook is the authority on format. What follows is the content every Pakistani CS and SE department expects, what each document is actually for, and how to write it without spending the last two weeks of final semester doing all of it at once.
What the full documentation set contains
| Document | What it answers | When to write it |
|---|---|---|
| Proposal | Why this project, and can it be finished? | Before approval |
| SRS | Exactly what the system must do, and how well. | Semester 1, before you build |
| Design document | How the system is structured: architecture, database, interfaces. | Semester 1, with the SRS |
| Test document | What you tested, with what input, and what happened. | As you build, not at the end |
| Final report | The whole story: problem, solution, results, limitations, future work. | Semester 2, assembled from the above |
| User manual | How someone who did not build it can run and use it. | After the build is stable |
Notice that four of the six are written before or during development. Groups that treat documentation as a final-semester task end up describing a system from memory, and it shows.
The SRS, section by section
The software requirements specification is the document supervisors scrutinise most, because everything else depends on it. Most departments follow the IEEE 830 structure or something close to it.
Want a ready file? Download our free SRS template for FYP (Word and PDF).
| Section | What belongs in it |
|---|---|
| Introduction | Purpose of the document, scope of the product, definitions and abbreviations, references. |
| Overall description | Product perspective, main functions in summary, user classes, operating environment, constraints and assumptions. |
| Functional requirements | Numbered, testable statements of what the system does, grouped by module. Each one needs an identifier so test cases can reference it. |
| Non-functional requirements | Performance, security, usability, reliability, portability — each with a number attached, not an adjective. |
| Use cases | Use case diagram plus a written description per case: actor, precondition, main flow, alternate flows, postcondition. |
| External interfaces | User interface sketches, hardware interfaces, any third-party API the system talks to. |
The single most common mistake is writing requirements that cannot be tested. “The system shall be fast” is not a requirement. “The system shall return search results within two seconds for a catalogue of up to 10,000 records” is, because someone can check it and write pass or fail next to it.
Number every requirement, for example FR-04 and NFR-02. In the test document each test case then cites the requirement it verifies, and your traceability is done without any extra work.
The diagrams you will be asked for
- Use case diagram — actors and what each can do. Keep actors to the roles that genuinely differ in permissions.
- Entity relationship diagram — your database. Supervisors look for normalisation, correct cardinality and sensible keys.
- Class diagram — for object-oriented projects, the main classes with attributes, methods and relationships.
- Sequence diagram — for two or three important flows, such as login or placing an order, not for every function.
- Activity diagram — the steps of a process that has branches worth showing.
- Architecture or deployment diagram — the components and where each runs.
Draw them from your own system. A generic diagram copied from a textbook is obvious to anyone who has supervised more than one batch, and it invites questions in the viva that you will not be able to answer.
Test documentation that takes an afternoon, not a week
Keep one table and fill it as you build. Each row is a test case with an identifier, the requirement it checks, the input, the expected result, the actual result and pass or fail.
Include the failures you later fixed. A test document where every single case passed on the first attempt reads as fiction, and supervisors treat it that way. Showing a defect, the fix and the re-test is evidence that you tested at all.
Writing the final report without a last-minute panic
The final report is largely an assembly job if the earlier documents exist. The parts that are genuinely new are the results, the limitations and the future work.
- Results — what the system does now, measured against the objectives from your proposal, one by one.
- Limitations — what it does not do, and why. Writing these yourself is far better than having the committee discover them.
- Future work — the honest next steps, which also shows you understand where the system stands.
Keep a running document from the first week with dated notes on decisions and why you made them. Every group that does this finishes the report in days instead of weeks.
FYP documentation questions
How long should FYP documentation be?
The final report is commonly sixty to a hundred pages including diagrams and appendices, and the SRS perhaps twenty five to forty of that. Departments vary, so check your handbook. Padding is easy to spot and gains nothing.
What is the difference between the SRS and the design document?
The SRS says what the system must do, in terms a non-programmer can check. The design document says how it is built: architecture, database schema, class structure and interfaces. Requirements first, design second, and the design should trace back to numbered requirements.
Can I write the documentation after finishing the code?
You can, and it is why so many reports are thin. The SRS and design exist to guide the build; written afterwards they become a description from memory, with no record of the decisions or the testing. Keep a dated notes file from week one even if you write the formal documents later.
Do I need UML diagrams if my project is not object oriented?
Use case and activity diagrams still apply to any system. Class diagrams only make sense for object-oriented designs; for a data-heavy project the entity relationship diagram and an architecture diagram carry more weight. Ask your supervisor which set your department requires.
What format should the documentation be submitted in?
Usually a bound hard copy plus a PDF, with the supervisor’s signature on the cover. Write in Word or LaTeX, keep a consistent heading structure, and generate the table of contents automatically so page numbers stay correct.
How many test cases are enough?
Enough to cover every functional requirement at least once, plus the obvious failure paths: empty input, wrong credentials, duplicate records, lost connection. Twenty well-chosen cases with real results beat a hundred that all say pass.
Related
Earlier stages: FYP proposal format and 70 FYP ideas for computer science students, or filter ideas with the FYP idea generator. After the degree: internships for computer science students and what the market pays. If your department also requires an internship, the internship weekly report format covers the weekly progress reports.