Project Rules (Read Carefully)
This semester project is designed to apply core SWE-401 topics: requirements gathering and system architecture. You are not required to build a complete working product.
Very Important: The main grading focus is Requirements + Architecture + Diagrams.
A small prototype is allowed, but it must be simple (no advanced features).
- Group size: 3–4 students per group.
- Scope limit: Maximum 4 core features + 1 optional feature.
- Not allowed: payments, real-time chat, live maps, AI features, complex integrations.
- Architecture style: choose ONE style only: Layered or MVC.
What You Must Submit (Deliverables)
All deliverables must be submitted as hard copies (printed documents).
- Hard Copy of Written Report: Properly formatted, bound report following the structure provided below.
- Hard Copy of Presentation Slides: Printed presentation slides (handout format recommended).
Submission Format: Both report and presentation slides must be printed and submitted physically.
Digital submissions are not accepted unless specifically requested by the instructor.
| Part | Deliverable | Required? | Notes (keep it simple) |
|---|---|---|---|
| A | Problem statement (5–8 lines) + Actors list | Yes | Who uses the system and why. |
| A | Functional requirements (8–12 bullet points) | Yes | Write as “System shall …”. |
| A | Non-functional requirements (6–8 bullet points) | Yes | Security, performance, usability, availability, etc. |
| A | Out of scope (3–5 bullet points) | Yes | Write what you will NOT build. |
| B | Use Case Diagram (1) + 3 Use Case descriptions | Yes | Pick 3 important flows only. |
| B | Architecture diagram (Component view) | Yes | UI → Backend → Database (plus optional Auth). |
| B | Class diagram (small: 5–8 classes) | Yes | Only core entities. |
| B | Sequence diagram (1 main flow) | Yes | One flow: e.g., “Book appointment”. |
| B | Deployment diagram (very basic) | Yes | Client + Server + Database. |
| C | Prototype (3–5 screens or simple console CRUD) | Optional | Only to show the idea; not a full app. |
You can draw diagrams using any tool (draw.io, Lucidchart, PowerPoint, etc.).
Report Structure (Table of Contents)
Your written report must follow this structure exactly. Include a table of contents at the beginning.
| Section | Content |
|---|---|
| 1. Table of Contents | List all sections with page numbers |
| 2. Introduction | Project overview, objectives, scope, organization of report |
| 3. Problem Statement | Clear description of problem, current state, proposed solution, stakeholders |
| 4. Requirements Analysis | Functional requirements, non-functional requirements, use case diagram, use case descriptions, actors |
| 5. System Architecture | Architectural style selection and justification, component diagram, deployment diagram, architecture description |
| 6. UML Diagrams | Use case diagram, class diagram, sequence diagram, activity diagram (if applicable), state diagram (if applicable) |
| 7. Design Patterns | At least 3 design patterns used, with justification and implementation approach |
| 8. Implementation Overview | Technology stack, prototype features, code structure (if applicable) |
| 9. Testing Strategy | Testing approach, test cases for critical functionalities |
| 10. Conclusion | Summary, reflections, limitations, future enhancements |
| 11. References | Properly formatted citations |
| 12. Appendices | Source code (if applicable), additional diagrams, screenshots |
Evaluation Rubric (Total: 10 marks)
Your project will be evaluated based on the following criteria. Total marks: 10.
| Component | Marks | Evaluation Criteria |
|---|---|---|
| Requirements Analysis | 2 | Completeness and clarity of functional/non-functional requirements, proper use case modeling, actors identification, out of scope definition |
| Architecture Design | 2 | Appropriate architectural style selection, clear justification, component design quality, deployment architecture clarity |
| UML Diagrams | 2 | Correctness of diagrams, proper UML notation, completeness, consistency across diagrams, clarity and readability |
| Written Report | 2 | Report structure and formatting, professional presentation, completeness of all sections, clarity of writing, proper table of contents, references |
| Presentation | 2 | Content quality and coverage, delivery and communication skills, prototype demonstration (if applicable), time management, ability to answer questions |
| Total | 10 | All components must be submitted as hard copies |
Important: Late submissions will be penalized. Ensure all hard copies are properly bound and submitted on time.
Presentation will be scheduled separately and attendance is mandatory for all group members.
Choose ONE Project Topic (11 options)
Pick one topic below. Keep it small: only 4 core features.
| # | Project |
|---|---|
| 1 | Clinic Appointment System |
| 2 | Library Issue/Return System |
| 3 | Hostel Room Allocation |
| 4 | Canteen Token / Order Queue |
| 5 | University Complaint Portal |
| 6 | Event Registration System |
| 7 | Parking Slot Management |
| 8 | Lab Inventory (Stock In/Out) |
| 9 | Simple LMS (Assignments) |
| 10 | Bus/Van Schedule & Check-in (Manual) |
| 11 | Office Visitor Entry Log |
Example Project (For Understanding Only)
This example is intentionally more detailed to show you what the deliverables look like. Your own project can be simpler.
Example Topic
University Complaint Portal
A system for students to submit complaints and track resolution status.
- Actors: Student, Admin, Staff/Technician
- Architecture style: Layered (one style)
- Core features (4): submit complaint, assign, update status, track status
Sample Requirements (short)
- FR1: System shall allow students to submit a complaint with category and description.
- FR2: System shall allow admin to assign a complaint to a staff member.
- FR3: System shall allow staff to update complaint status (Open/In-Progress/Resolved).
- FR4: System shall allow students to view the status of their complaints.
- NFR: Students can only view their own complaints (privacy).
- Out of scope: Live chat, payments, AI auto-classification.
Diagram 1 — Use Case Diagram (example)
Students should draw this properly using a diagram tool. This figure shows the expected idea: actors + use cases inside a system boundary.
Diagram 2 — Layered Architecture (example)
Keep it simple: UI → Backend layers → Database. (Students can choose MVC instead, but only one style.)
Diagram 3 — Sequence Diagram (example: Submit Complaint)
Only one sequence diagram is required: choose the most important flow.
Diagram 4 — Deployment Diagram (example)
Keep deployment very basic: client + server + database.
Note: This is a sample work. Your project should have more details and depth than this example.