SRS Team4

Software Requirements
Specification
for
Even-SpliT
Version <1.0>
Prepared by
Group 4: Group Name: <Runtime Terror>

Mohak Singh Rana 210614 mohaksr21@iitk.ac.in
Mihir R Deshpande 210609 mihirrd21@iitk.ac.in
Bornadhya Abir Rajbongshi 210273 bornadhya21@iitk.ac.in
Rajat Gattani 210813 rajatg21@iitk.ac.in
Dhruv Garg 210339 dhruvgarg21@iitk.ac.in
Shourya Trikha 210994 shouryat21@iitk.ac.in
Antriksh Gupta 210159 antrikshg21@iitk.ac.in
Manasvi Jain 210581 manasvij21@iitk.ac.in
Bhavaj Singla 210265 bhavajs21@iitk.ac.in
Aditya Ajmera 210056 adityaa21@iitk.ac.in
Course: CS253
Mentor TA: Mr. Abhinav Dudeja
Date: 27-01-2023
Software Requirements Specification for <Even-SpliT>
CONTENTS................................................................................................................................................... 2
REVISIONS ................................................................................................................................................... 3
1 INTRODUCTION .................................................................................................................................. 4
1.1 PRODUCT SCOPE ........................................................................................................................... 4
1.2 INTENDED AUDIENCE AND DOCUMENT OVERVIEW ............................................................................ 4
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS................................................................................ 5
1.4 DOCUMENT CONVENTIONS ............................................................................................................. 5
1.5 REFERENCES AND ACKNOWLEDGMENTS ......................................................................................... 6
2 OVERALL DESCRIPTION ................................................................................................................... 7
2.1 PRODUCT OVERVIEW ..................................................................................................................... 7
2.2 PRODUCT FUNCTIONALITY .............................................................................................................. 8
2.3 DESIGN AND IMPLEMENTATION CONSTRAINTS.................................................................................. 9
2.4 ASSUMPTIONS AND DEPENDENCIES ................................................................................................ 9
3 SPECIFIC REQUIREMENTS ............................................................................................................. 10
3.1 EXTERNAL INTERFACE REQUIREMENTS ......................................................................................... 10
3.2 FUNCTIONAL REQUIREMENTS ....................................................................................................... 13
3.3 USE CASE MODEL........................................................................................................................ 15
4 OTHER NON-FUNCTIONAL REQUIREMENTS ............................................................................... 22
4.1 PERFORMANCE REQUIREMENTS ................................................................................................... 22
4.2 SAFETY AND SECURITY REQUIREMENTS ........................................................................................ 22
4.3 SOFTWARE QUALITY ATTRIBUTES ................................................................................................. 22
5 OTHER REQUIREMENTS ................................................................................................................. 24
APPENDIX A – DATA DICTIONARY ......................................................................................................... 25
APPENDIX B - GROUP LOG ..................................................................................................................... 26
Revisions
Version Primary Author(s) Description of Version Date Completed
Draft Type Full Name Information about the revision. This table 00/00/00
and does not need to be filled in whenever a
Number document is touched, only when the version
is being upgraded.
1 Introduction
1.1 Product Scope
We aim to build a website to help students track their financial and academic status. Many
transactions occur every day amongst friends, hall canteens, mess, and other available
services on campus. It is easy to lose track of expenses in such situations. This calls for a
portal that maintains a neat record of all expenses incurred. Often, in large groups, it is
cumbersome to settle dues. Our portal will allow you to systematically add and settle dues
incurred in large groups, making the logistics much easier (for instance, when you go to the
mall with all your friends).
We also aim to create a personal calendar, which would be personalized according to the
student's requirements - club interests, branch, etc. All the desired events, classes, exams,
and clashes will be portrayed for the student's perusal. Event managers will have access to
add and manage their current events. This will help a student conveniently manage his time,
improving his college experience.
1.2 Intended Audience and Document Overview

The document is intended for:
• Software Developers who will design the software as per the requirements of a
particular institution/company, in this case, the group members.
• Project Managers who will supervise the planning and execution of the software
development procedure, in this case, the TAs and the instructor.
• Testers who will perform a quality check of the designed software and give their
feedback on the interface, areas of improvement, etc.
• Users who will be the customers of the software, in this case, our entire student
community and coordinators of various clubs and societies.
Section 1:
In this section, we provide some basic information that would be useful in reading the SRS,
such as document conventions, abbreviations, etc. The reader may choose to skip the
section if they are familiar with the basic terminologies. In any case, this section will serve
as a helpful collection of information to clarify any confusion that may occur while reading
the document.
Section 2:
This section offers a bird’s eye view of the software system and its functionalities,
assumptions, and dependencies. This will be a useful read for those seeking to familiarize
themselves with the system at a quick glance. A reader is encouraged to read this part as it
provides a good basis for understanding the next section of the SRS.
Section 3:
This section contains detailed information about the software and explains its functions in
detail through the use of multiple diagrams. This is essential for end-users, clients, and
developers as it will serve as a guide in the development process and an instruction manual
for end-users.
Section 4
Important non-functional requirements are expounded here. This is of special importance to
the developers of the software.
1.3 Definitions, Acronyms and Abbreviations

• SRS Software Requirement Specification
• DBMS Database Management System
• HTTPS Hyper Text Transfer Protocol Secure
• JSON JavaScript Object Notation
• CSS Cascading Style Sheets
• UI User Interface
• UX User Experienc
• DUGC Department Under-Graduate Committee
• MTTF Mean Time to Failure
• Response Time It is the time a system/functional unit takes to react to a given
input
1.4 Document Conventions

While preparing this document, to make readability user-friendly and important parts clear, we have
used the following conventions:
● The headings of all the sections are written in bold and underlined using Arial font size 14.
● The headings of subsections are bold and written in the same font as that of content using font
size 13.
● The content of the section is written in Arial font size 11.
● Any important term or short form is written in bold.
● The alignment of the whole content is justified.
● Text has been indented wherever required to highlight the hierarchy of the content.
● The document follows the IEEE formatting, indenting, and numbering conventions. Any deviations
from the same will be explicitly specified.
1.5 References and Acknowledgments

References: -
• Style guide (for this document): IEEE Editorial Style Manual (Online)
• UI Interface: Reactjs and Tailwind
Acknowledgments: -
We would also like to acknowledge the help of our TA Mr. Abhinav Dudeja and our instructor
Mr. Indranil Saha for guiding us through the document, and providing this SRS template
2 Overall Description
2.1 Product Overview
The aim of our product is to help students manage their time and expenses in an efficient
way. The campus community lacks an integrated calendar organised in a single portal,
which displays the academic timetable and events of all club and societies. Various clashes
between events make it difficult for students to schedule their day. Our integrated calendar
will assimilate the various events and display their details according to the student's interests.
Another important and often poorly managed aspect of a student's life is their expenditure.
Travelling in a group of friends is a common occurrence. Keeping track of every transaction
that takes place is cumbersome in a large group and often leads to uneven expenditures.
Our product will help manage the expenses incurred in such situations. It also allows
students to document their personal expenses on food, groceries, travel, etc. and help them
optimise their finances.
2.2 Product Functionality

• Student and Admin login using their username and password set while registering.
• Sign up using IITK credentials and phone number.
2.2.1 Expenses
• Can view and settle pending one-to-one transactions amongst friends as well as
transactions in a group of friends.
• Generate a detailed summary of weekly / monthly expenses
• Simplify expenses in groups such that number of transactions are minimised.
• Help optimise expenses by setting a threshold for expenditure
• Club admins can monitor the status of sponsors and other sources of funds.
• Club admins can keep a log of bills of various transactions, that are visible to other
admins and concerned authorities in order to make the system transparent.
2.2.2 Calendar
• The user can view the monthly, weekly and hourly view of the calendar.
• Filtering events using Tags: Users can filter events according to clubs, batch,
department, etc.
• Additionally, users can add personal events of their choice that will be visible only to
them.
• Clashes: The user will be able to see all the clashes
• Reminders: Users will be notified about events that they have prioritized.
• Respective admins can add events that will be visible to everyone.
• Admins can send notification to students interested in their club.

2.3 Design and Implementation Constraints

• Event database forms an integral part of the relevance of the software, it is admin’s
responsibility for the timely addition (and updation) of the events.
• Expenses database forms an integral part of the relevance of the software, it is user’s
responsibility for the timely addition (and updation) of the expenses.
• The Server should have sufficient memory and resources available in order to
accommodate and serve all the requests and the data requested by the users
concurrently.
• The user shall not be able to access the data available at the admin account. Also,
the data of one user shall not be visible to any other user .
2.4 Assumptions and Dependencies

• The number of users who use this application shall never be greater than 10,000.
• The number of users in an expenses group shall never be greater than 100.
• Only one admin is adding events at particular time, so that clashes are minimised.
• At any point of time, there shall be at least one account with admin privileges for each
event conducting body so that timely updation of the calendar is possible.
• Upcoming new technology shall not affect the execution of the application.
3 Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
Login
Different login options for Normal User
and Admin.
UserLogin Admin Login
General General Dashboard is the welcome screen

Dashboard shown to Normal Users upon successful login.
The Profile tab will allow users to view their
profile, change their password, sign out, etc.
The Calendar and finances options will take the
Profile Calendar Finance Alerts user to the respective home pages. Finally, the
user will be able to see reminders and alerts in
the alerts tab.
Calendar
Option
On the calendar home page, the

Monthly View Calendar options button will open a list
of options like switching the view of the
calendar to monthly, weekly or hourly.
The users can also add an event of their
Weekly View Hourly View Add an Event Filters choice. Furthermore, users can filter the
events using tags.
Batch-Wise
Department-
Wise
Clubs/Society-
Wise
Others
The finance home page opens with two tabs displayed –
1. Manage Tab
2. Payment History Tab
On opening the Manage tab, depending on which login we are using (student / admin), we will
have different UIs. For user login, we will have different options, such as settling dues with friends
and keeping track of personal expenses. For Admin login, we will have the option to add expenses
as regular or event specific and check the status of sponsors and funds.
On opening the Payment History tab, we can Monitor our expenses by comparing them with the
previous week and month and set a limit for weekly and monthly expenses, which will notify the
user via email on exceeding the limit.
UI Designs
• Sign-Up/ Sign-In Page
Portal to register (only for students) and login (for both students and admins).
On logging in, a dashboard (homepage) will be visible.
• Dashboard
A “Calendar” and an “Expenses” tab. User can access his profile details on the top right
corner. Prioritised alerts are also displayed on the dashboard.
3.1.2 Hardware Interfaces
• Support for modem and Ethernet card – that is, appropriate drivers of compatible modem
and Ethernet card are installed for accessing web pages over the internet or intranet.
• The server side of the system must be connected to IITK intranet.
3.1.3 Software Interfaces
• The server-side components of the software system must operate within a Linux operating
system environment.
• The client-side components of the software system must operate with modern web browsers
environments like Apple Safari 7+, Google Chrome 44+, Microsoft Internet Explorer 10+,
Mozilla Firefox 40+.
• We will use three databases for storing the following: -

o User login credentials
o Calendar data – event details, filters and priorities of users
o Finances
• We will use MongoDB as our DBMS.
• The database and its management systems will be deployed on the server side, the final
client application delivered would not be independent of this.
3.2 Functional Requirements

3.2.1 The calendar will display all the upcoming events that the user might be
interested in and the resulting clashes among the events.
• The user shall be able to see both the main and personal calendar in different views like
monthly or weekly or hourly view. In the hourly view, the user will be able to see the events
and a small description like venue of event.
• The user shall be able to apply filters/tags according to his choice and in any view of
calendar, only the events of applied filters will be visible.
• In the hourly view, different events will be shown on hourly basis so the user can see if
there is any clash between any two events.
3.2.2 All event conducting bodies will be able to see other events and will be able
to plan their events accordingly to avoid any clashes.
• Each club or society coordinator shall be able to login as admin. The admin will be able to
see all the events and their details like venue, time, etc. This will allow admin to plan the
timings and venue for the events easily without any clash with any other event.
• The admin shall be able to add the event and details of event such as timings and the
venue of the event. This event will be visible in the main calendar of all the campus
community.
• The user will have a personal calendar where the user will be able to add any of his/her
personal events. The user will also be able to add any of the event from the main calendar
he/she might be interested in.
• The user will also be able to prioritize any of the events of interest from the personal
calendar. The user will be notified about the prioritized events 30 minutes before the event
in the notification tab.
3.2.3 Settle one-to-one transactions among friends as well as transactions in a

group of friends.
On logging into the expenses portal, two tabs will be visible to us:–
• A “Friends” tab catering to the one-to-one transactions amongst accounts that the user has
added. The user will be able to manage (add / settle / request / delete) dues with their
friends as required.
• A “Groups” tab, which displays the various groups the user is part of. The user can view
detailed transaction activity by clicking on a particular group. This would display the amount
every member owes to others and the amount others owe him. Clicking on a particular
friend will allow the user to manage dues specifically with that friend. A “simplify" option will
be available in groups, for settling all dues following minimum number of transactions.
3.2.4 Get a detailed summary of weekly/monthly expenses.
• The user can view all his expenses organised into a neat pie chart. He can also view
expenditures that exceeded the threshold.
• He can also view a detailed history of all his expenditures according to the filters he
chooses.
3.3 Use Case Models
CALENDAR
FINANCE
The above use case diagrams provide an overall view of the processes and actors that our
application will be dealing with. The main actors specified here are:
• Students – Student community in the campus
• Club Co-ordinators – Governing authority of the club as well as this application

(i.e., will have the admin access)
• Branch DUGC’s - Governing authority of the department as well as this

application (i.e., will have the admin access)
3.3.1 Use Case #1 (U1)
Author – This use case was written by Manasvi Jain.
Purpose - To display the events for a particular user according to their interest and display the
clashes involved in it
Requirements Traceability – The student must add his interests and personal timetable in order
to get access to these events and filter out the rest of the events.
Priority - The priority of this use case is high as it is one of the main features of this application
and any problems in this use case will defeat one of the main purposes of this application
Pre conditions - The addition of interest and personal timetable must have started from the side
of the actor, here the students
Post conditions - The students can check what new event or talk is getting hosted that day that
he or she might be interested in and if it is clashing with any other event in their calendar.
Actors – Actors in this use case are the student and club coordinators and branch DUGCs are
acting as the admins.
3.3.2 Use Case #2 (U2)
Author – This use case was written by Manasvi Jain.
Purpose - To add various events in the calendar by the admin
Requirements Traceability – The admin who is going to add the events must have signed up in
their respective portal.
and any problems in this use case will defeat one of the main purposes of this application.
Preconditions - The admin who has to add the event should make sure it is not clashing with
any other similar event
Postconditions - The event would be added to the calendar of the students who have chosen
that club or specific branch in their filter.
Actors – The actors involved in this case are club coordinators and branch DUGCs acting as the
admins.
3.3.3 Use Case #3 (U3)
Author – This use case was written by Mohak Singh Rana.
Purpose - To minimize the number of transactions in a group using a simplification feature
Requirements Traceability – All the users who shared the expense, first needs to form a group on
the website. Then the group members must add the amount paid by them.
Priority - Priority of this use case is medium, as if this system fails, it will affect a group of people
but won’t bring down the whole application.
Pre conditions - All the transactions added by the users needs to be specific, that is they should
mention who paid for the service and among how many people the service was shared.
Post conditions - The users will see the final amount they need to pay (with minimum number of
transactions)
Actors – Actors in this use case are the students acting as the users.
3.3.4 Use Case #4 (U4)
Author – This use case was written by Mohak Singh Rana.
Purpose – To add various expenses and their bills by the admin.
Requirements Traceability – The admin who is going to add the expense must have signed in in
the portal and needs a bill of the expense.
and any problems in this use case will defeat one of the main purposes of this application
Pre conditions – The admin should clearly specify the details of the transaction and also upload the
bill of the expense.
Post conditions – The club will be able to see the summary of the expenses and the system will
become more transparent.
Actors – Actors in this use case are the club coordinators and branch DUGCs acting as the admins.
3.3.5 Use Case #5 (U5)

Author – This use case was written by Mihir R Deshpande.
Purpose – To manage (add / settle / delete / optimize) personal expenses, request money from
friends.
Requirements Traceability – The user must be logged in.
and any problems in this use case will defeat one of the main purposes of this application.
Preconditions – The user has transactions yet to be documented or modified. The user could
also be in a situation where he needs to request money from a friend. The user might also want
to monitor his expenses over the past week / month.
Postconditions – The transactions have been added / modified according to the user’s desire. In
the case that a user requests money, a notification will be sent to the concerned friend. The user
can view a summary of his expenses over the past week / month neatly organized graphically.
Actors – Actors in this use case are the students (not admins) using the portal to keep a log of
personal expenses.
3.3.6 Use Case #6 (U6)
Author – This use case was written by Antriksh Gupta.
Purpose – This use case describes the process of adding a personal event by a user to their
calendar.
Requirements Traceability – The user who wants to add a personal event must be logged into
their account.
Priority - The priority of this use case is medium as if this system fails, they would still be able to
view events that are part of the common calendar.
Preconditions – The user should check that their time and date of their event is not clashing with
another event (The user can still add a clashing event if they wish so).
Postconditions – The personal event would be added to the calendar of the user and would be
visible only to them.
Actors – The actors involved in this case are students acting as the users.
4 Other Non-functional Requirements

4.1 Performance Requirements
• Response time: The system should be interactive and fewer delays involved. The average
response time should be less than 1 second at the time of launch and less than 3 seconds
otherwise.
• Workload: The system should be able to handle 200 people at a time efficiently.
• Performance related to storage, memory, and processing should follow industry-

recommended practices to minimize resource requirements.
4.2 Safety and Security Requirements

• Proper login mechanisms should be used to avoid hacking.
• Periodic backup of the entire database will be taken.
• Information transmission should be securely transmitted to the server without any changes
in information.
• Secure storage of passwords will be done after salting and hashing the passwords. In other
words, the system admin can only verify if the password is correct but won’t know what the
password submitted by the user was.
• The minimum set of browsers that must be supported is: • Apple Safari 7+ • Google Chrome
44+ • Microsoft Internet Explorer 10+ • Mozilla Firefox 40+.
•A notification will be sent to the concerned people whenever a transaction is added.
4.3 Software Quality Attributes

4.3.1 Maintainability
• The architecture, design, implementation and documentation of the software must be such
that they make the system reduce maintenance overhead as much as possible.
• Fixing a security defect, including updating of the documentation and testing, must not
take more than two working days.
• The average work time required to add a minor feature, including documentation and unit
testing, should be less than one person a week.
4.3.2 Availability
• In case of a server crash, the system state must be restored within two hours.
• Expenses will see a boom during the vacations as a lot of groups will be going on trips.
The system availability needs to be enough for this purpose.
• A lot of events are conducted by various clubs during the summer break. The system
should be enough to provide all the functions of the calendar in the peak time.
4.3.3 Reliability
• The MTTF (Mean time to failure) shall be more than one week.
• The system must undergo extensive feature testing, load testing, and regression testing
prior to release and/or deployment.
• The system should be reliable in giving correct results consistently.
4.3.4 Portability
• We are using React with tailwind CSS library to design the front-end par of our
application, thus our application is portable, responsive and can run on any modern web
browser.
5 Other Requirements
• Permission will be required for utilising OTPs for the authentication process as this will
require sending automated emails to the student’s IITK email id.
• Three databases would be required, one for storing the authenticity related information like
username, passwords. The second will be for storing calendar database and the last will be
storing expenses database. These databases will include information of both admins and
student users.
• Since our software will be used by club admins and branch DUGCs, we have to maintain
confidentiality in specific areas (for eg: expenses of a club shouldn’t be publicly visible).
Permissions would be needed for making such a software open-source.
NOTE
We will try our best to develop both the components – calendar as well as finances portals.
However, our primary focus will be on the finances portal.
Appendix A – Data Dictionary
S.No. Type Name Description
1. Actor Club Coordinator Governing authority of the club and this

application (i.e., will have the admin access)
2. Actor Branch DUGC’s Governing authority of the Department and

this application (i.e., will have the admin
access)
3. Actor Students Student community in the campus

Appendix B - Group Log

Date Timings Duration Minutes
Idea Suggestions by everyone

4 main ideas were presented-
• Entry-exit portal
• Campus shopping portal
• Calendar
07-Jan 21:00-00:00 3 hr • College finances
• Preliminary Discussion on feasibility and usefulness of
ideas.
• It was commonly felt that a lot of issues are faced in managing
the expenses, settling expenses amongst friends and also
keeping track of various events to be held.
• A software solution for this problem was imperative.
10-Jan 20:00-23:00 3 hr • Finalisation of the idea of EvenSplit.
• Meeting with teaching assistant Mr. Abhinav Dudeja.
• Explained our project idea and discussed the logistics with our
TA.
• We also discussed problems that we might face during the
18-Jan 18:30-19:30 1 hr project.
• Brainstorming of final ideas and discussion on possible use
cases, features, data flows.
• Exploration of possible implementations, challenges, tech
stacks.
• It was decided to use React with tailwind CSS library to build the
20-Jan 21:00-23:00 2 hr front end part of our application and MongoDB as our DBMS.
• The system will have 2 access levels.
• The levels will be students and admins with admin having some
22-Jan 21:00-23:00 2 hr special powers.
• We started working on sections 1,2 and 3 of SRS.
• Functional requirements were discussed and formally specified
in the SRS.
• Work was distributed amongst us - part of us worked on
23-Jan 21:00-00:00 3 hr calendar part and remaining worked on expenses part.
• The functionalities for each level were decided
• The UI and UX interface was finalized for each level.
• Construction of use case models was distributed and started.
24-Jan 20:00-1:00 5 hr • A UI UX model was distributed and started as well.
• Construction of Use case Models was completed and agreed
upon.
• Construction of the login page was completed and UI design
was agreed upon.
25-Jan 18:00-00:00 6 hr • Incomplete sections of the SRS were distributed for completion.
26-Jan 21:00-00:00 3 hr • Finalisation of the SRS.

SRS Team4

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRS Team4

Uploaded by

Copyright:

Available Formats

Software Requirements

Group 4: Group Name: <Runtime Terror>

Mentor TA: Mr. Abhinav Dudeja

1.2 Intended Audience and Document Overview

1.3 Definitions, Acronyms and Abbreviations

1.4 Document Conventions

● The content of the section is written in Arial font size 11.

● Any important term or short form is written in bold.

● The alignment of the whole content is justified.

1.5 References and Acknowledgments

2.2 Product Functionality

• Sign up using IITK credentials and phone number.

• Generate a detailed summary of weekly / monthly expenses

• Simplify expenses in groups such that number of transactions are minimised.

• Help optimise expenses by setting a threshold for expenditure

• Clashes: The user will be able to see all the clashes

• Respective admins can add events that will be visible to everyone.

• Admins can send notification to students interested in their club.

2.3 Design and Implementation Constraints

2.4 Assumptions and Dependencies

UserLogin Admin Login

General General Dashboard is the welcome screen

On the calendar home page, the

The finance home page opens with two tabs displayed –

• The server side of the system must be connected to IITK intranet.

3.1.3 Software Interfaces

• We will use three databases for storing the following: -

• We will use MongoDB as our DBMS.

3.2 Functional Requirements

3.2.3 Settle one-to-one transactions among friends as well as transactions in a

3.2.4 Get a detailed summary of weekly/monthly expenses.

3.3 Use Case Models

• Students – Student community in the campus

• Club Co-ordinators – Governing authority of the club as well as this application

• Branch DUGC’s - Governing authority of the department as well as this

3.3.1 Use Case #1 (U1)

Author – This use case was written by Manasvi Jain.

3.3.2 Use Case #2 (U2)

Author – This use case was written by Manasvi Jain.

Purpose - To add various events in the calendar by the admin

Author – This use case was written by Mohak Singh Rana.

Purpose - To minimize the number of transactions in a group using a simplification feature

3.3.4 Use Case #4 (U4)

Author – This use case was written by Mohak Singh Rana.

Purpose – To add various expenses and their bills by the admin.

3.3.5 Use Case #5 (U5)

Requirements Traceability – The user must be logged in.

4 Other Non-functional Requirements

• Performance related to storage, memory, and processing should follow industry-

4.2 Safety and Security Requirements

• Periodic backup of the entire database will be taken.

•A notification will be sent to the concerned people whenever a transaction is added.

4.3 Software Quality Attributes

• The system should be reliable in giving correct results consistently.

Appendix A – Data Dictionary

S.No. Type Name Description

1. Actor Club Coordinator Governing authority of the club and this

2. Actor Branch DUGC’s Governing authority of the Department and

3. Actor Students Student community in the campus

Appendix B - Group Log

Idea Suggestions by everyone

You might also like