This document provides guidance for final year project groups for the 2015/2016 year. It discusses potential project topics, including a library management system, student performance management system, and daily attendance system. For each topic, it lists example functional requirements and considers how the system could support various stakeholders. The document emphasizes properly scoping the project to approximately 300 hours of work. It also provides advice on integration vs interfacing with other systems and best practices.

1. Final Year Project Guidance Session – 2015/2016
OpenArc Campus
Upekha Vandebona
upe.vand@gmail.com
2015 – 10 - 11

2. Can you differentiate non-functional and
functional requirements now?
Any domain related problem,
Ask from “Quora” -
https://www.quora.com

4. Supervisor Agreement Form

5.  Your system’s title sometimes
defines your scope
• Select a suitable title for your system
 Scope should express 300 hours of
work.
• Time Management. Errrr!!!!

6. Automatic DB Backups **
User Management
• Authentication & Authorization
Master Data, Reference Data
Management
CAPTCHA **
** - Optional, but beneficial in general

7. Managerial Reports
Operational Reports

9.  Group1 - Library Management System for Thissa
Vidyalaya
 Group 2 - Student Performance Management System
Gamini Vidyalaya
 Group3 - Daily Attendance System for Parakrama IT
Training Center
(Traditional Client)
(Talkative Client)
(Non-Talkative Client)

10. Traditional Client
• Evolutionary Prototyping
Doesn’t know how to tell in a
computer system perspective.
(ex: Fines)

11. No member involvement required for
client. System is solely for managerial
purposes.
• Enough Scope ???
 No Reserving Books, No Cancel Reserving, No
Previews and Reviews… etc.

12.  Browsing, Filtering & Searching Books
• By Category, Author, Title…..etc
• Output Availability
• Output Location
 Maintain Books data
• Copies, Editions
• Categories, Authors…etc
• Location

13.  Lending / Receiving / Removed (Decayed, Not
returned…)
• Book Status Maintain
 Members – (Interface with a student management
system???)
• Student Name
• Class / Year
 Fines Parameterization and Generation accordingly
• Late returning, Damages…etc

14. Reports / Charts – Information (By year, By
term)
• Fines reminder notice
• Fines received
• Books borrowed
• …etc

15. More on Decision Support
Purchases / Expenses
• Books
• Furniture
Value Added Features

16. Sole purpose is to
make computer system
supportive to improve
student performance

17.  Categorize, sub categorize and define
general events
 Define point weights for general events
 Student Data (Interface with a student
management system???)
• Address (where he lives effect performance – hostel,
with relatives, home)
• [Issue of privacy – Sensitive data]
 Student participation on events
• Negative behavior

18. Parents Involvement
• View, Inquiry, Chat/Messaging (Scheduling)
Teachers Involvement (Class teacher,
Subject teacher)
Student Involvement
Reports / Charts – Information (By year, By
term)

19. More on Decision Support
• Alerting on negative performance
Value Added Features
• Character Certificate Generation

20. Sole purpose is to
automate the current
process.

21. Use a device Vs data entry?
• Fingerprint, card reader… etc.
• Cost Benefit Analysis

22.  Attendance Marking
 Student Data (Interface with a student
management system???)
 Course - Subject Data / Schedule
 Monitoring & alerting negative attendance
behavior
• (Every course doesn’t need monitoring)

23. Parents Involvement
• Messaging parents on negative attendance
Lecturers Involvement
Reports / Charts – Information (By year, By
term)

24. Include Scheduling Component
• Room/Lab
• Lecturer
• Time
• Course – Subject
• Schedule Messaging students & lecturer
• Lecture Cancelling Messages
More on Decision Support

25. Integration vs. Interfacing
• http://www.lokisys.com/2015/01/integration-vs-
interface
Best Practice
• Don’t try to write on their database from your
system. Pass data to them, they will deal with it.
• Same goes the other way.

27. Draw the current business process in a
flow diagram

28. List down problems in the current system.
Search and list down Similar Systems.

29. Identify Actors
Identify Use Cases