Software Design Document for a Final Year Project

A software design document (SDD) for a final year project is a written plan that explains how your system is built: its architecture, data model, interfaces and the reasons behind each choice. A good one has about ten short sections, is started before the code, and stays small enough that you will actually keep it updated. If you want to know how to write an SDD without padding it to a page count, the outline below is where to begin. I am a final-year Computer Science student at KFUEIT. I documented the complete system architecture, database design and API workflows of my project GoCart in a 40+ page SDD, and that experience is why I write about this topic.

What is a software design document and who reads it?

The requirements document (often called an SRS) says what the system must do. The SDD says how you will build it. Some departments merge the two into one report, so check your template first. The IEEE 1016 standard on software design descriptions is a common reference if your supervisor asks for one. Three readers matter:

Your supervisor, who wants to see that the design is feasible before you spend months on it.
Your examiners, who use it to judge whether you made deliberate decisions or just accumulated code.
You, three months from now, trying to remember why the orders table has a separate status history.

Write for the third reader and the other two are usually satisfied.

How do you write an SDD, section by section?

Here is an outline you can paste into a markdown file and fill in. The order follows how a reader moves from the problem to the finished system.

Markdown

# Project name: Software Design Document

1. Introduction and scope
   - problem statement, goals, what is explicitly out of scope
   - definitions and abbreviations
2. Stakeholders and requirements
   - user roles and what each can do
   - functional requirements with IDs (FR-01, FR-02 ...)
   - non-functional requirements (performance, security, usability)
3. System architecture
   - high-level diagram: client, server, database, third-party services
   - technology choices and why
4. Database design
   - ER diagram, table or collection descriptions, key constraints
5. API design
   - endpoint list, request and response shape, error format, auth rules
6. UI flow
   - screen list, navigation between screens, wireframes for key pages
7. Security design
   - authentication, authorization per role, data protection
8. Deployment
   - environments, hosting, environment variables, build and release steps
9. Testing plan
   - test levels, test cases mapped to requirement IDs
10. Risks and future work
   - what could go wrong, what you would build next

Section 2 deserves the most care, because every later section refers back to it. Give each requirement an ID now. It costs five minutes and pays off when you reach the testing plan.

How deep should each section go?

Go as deep as a new developer would need to build that part without asking you questions, and stop there. Two pages with clear decisions beat ten pages of textbook definitions. For the database, list each table or collection with its fields, types, keys and relationships. If you use an ORM, the schema file is a good source to describe from, and the post on Prisma schema design for an e-commerce database shows how to think about those relationships. For the API, one line per endpoint is the right level. A plain text list like this is enough:

Text

POST /api/orders
  who:      customer (logged in)
  body:     list of product ids with quantities, shipping address id
  success:  201 with the new order id and status "pending"
  errors:   400 invalid body, 401 not logged in, 409 item out of stock
  covers:   FR-14

PATCH /api/orders/:id/status
  who:      vendor who owns the order, or admin
  body:     new status
  success:  200 with the updated order
  errors:   403 wrong role, 404 unknown order, 422 invalid status change
  covers:   FR-17

Notice the covers line. It ties each endpoint back to a requirement, which makes the document checkable. If you are unsure which HTTP method fits which action, the MDN reference on HTTP request methods is a reliable place to confirm. For security, name the mechanism and the rule. "Vendors can only change orders that contain their own products" is a useful design statement. "The system is secure" says nothing. The post on role-based access control in Next.js with Prisma gives a concrete way to express such rules.

Which diagrams are worth drawing?

Draw a diagram when it answers a question that prose answers badly. Five types cover most student projects:

A use case diagram shows which role can do what. Put it next to the requirements.
An architecture diagram shows the main parts (browser, server, database, payment provider, background jobs) and the direction of calls between them.
An ER diagram shows entities, keys and relationships. It belongs in the database section.
A sequence diagram shows one workflow over time, for example placing an order from click to confirmation. Pick the two or three flows that are hardest to follow in text.
A UML class diagram is useful when your code is object-oriented, such as a Java backend. For a mostly functional or schema-driven codebase it often duplicates the ER diagram, so skip it.

The UML notation is maintained by the Object Management Group, and the UML specification page at OMG is the authoritative source if your examiner is strict about symbols. Text-based tools such as Mermaid or PlantUML let you keep diagrams in the repository as plain files, which helps with the next problem.

How do you keep the SDD in sync with the code?

An SDD goes stale the moment the code changes and nobody touches the document. A few habits reduce that:

Keep the document in the same repository as the code, as markdown, so a change to both can ship in one commit.
Store diagrams as text (Mermaid or PlantUML) so a diff shows what changed.
Generate what can be generated. A Prisma schema or an OpenAPI file is the real source for tables and endpoints, so link to it instead of retyping it.
When you change a design decision, add a one-line entry to a short decision log: date, what changed, why.
Review the document at each milestone, not only before the final submission.

If the design changes during development, that is normal. Record the change and the reason, and the document shows the judgment you used along the way.

What mistakes make a final year project SDD weak?

Writing it after the code. The document turns into a description of whatever happened to get built, with no alternatives considered. Even a rough first version before you start coding forces the questions about data and roles that are cheaper to answer on paper. Copying generic text. Paragraphs on what a database is or what REST means fill pages without telling the reader anything about your system. Spend those words on your own choices: why one database over another, why this role model. No traceability from requirement to test. If FR-14 exists, there should be a design section that realizes it and at least one test case that checks it. The simplest way is a three-column list in your testing plan:

Text

FR-14  place an order     design: 5.2 POST /api/orders    tests: TC-14a valid order, TC-14b out of stock
FR-17  update order status design: 5.3 PATCH status       tests: TC-17a vendor allowed, TC-17b customer rejected

Two more problems show up often. Diagrams with no explanation leave the reader guessing, so give each one a sentence on what to notice. And a risks section that says "none" looks like you did not think about it. Third-party API limits, a teammate being unavailable and scope creep are all realistic entries. For a larger system, an architecture walkthrough of a real project helps you calibrate. The post on how to build a multi-vendor e-commerce platform describes the kind of structure that the architecture and API sections of an SDD would capture.

A quick checklist before you submit

Every functional requirement has an ID, a design reference and a test case.
The scope section says what you are not building.
Each diagram has a caption and is referred to in the text.
API endpoints list the role allowed, the success response and the errors.
The deployment section lets someone else run the project from scratch.
The risks section names at least three real risks with a plan for each.

Cover photo from Unsplash.

Software Design Document for a Final Year Project

What is a software design document and who reads it?

How do you write an SDD, section by section?

How deep should each section go?

Which diagrams are worth drawing?

How do you keep the SDD in sync with the code?

What mistakes make a final year project SDD weak?

A quick checklist before you submit

Recent posts