MIS605 - Systems Analysis and Design: ABC University Enrolment Report

This report provides a comprehensive analysis of an online student enrolment system for ABC University, addressing the need for a more efficient and less error-prone process. It delves into the core aspects of systems analysis and design, beginning with an introduction to the project and its stakeholders, which include the Pro Vice Chancellor, Program Directors, Enrolment Officers, Time Tabling Officers, the University itself, and the students. The report identifies the key actors within the system, outlining their interactions and roles, such as the Student, Timetabling Officer, Enrolment Officer, and Program Director. It then details both the functional and non-functional requirements of the system, specifying the essential functions like student enrollment, payment processing, and timetable generation, along with quality attributes such as performance, usability, and security. Furthermore, the report incorporates use case modeling, presenting diagrams and descriptions to illustrate the system's business processes, including the critical use cases of making payments and logging in. The aim is to create a robust and user-friendly online enrolment system to streamline the enrollment process and improve the overall student experience at ABC University.

Running head: SYSTEMS ANALYSIS AND DESIGN
SYSTEMS ANALYSIS AND DESIGN
Name of the Student
Name of the University
Author Note

1SYSTEMS ANALYSIS AND DESIGN
Table of Contents
Introduction......................................................................................................................................2
Project Stakeholders........................................................................................................................2
Actors...............................................................................................................................................4
Functional Requirements.................................................................................................................5
Non-functional Requirements..........................................................................................................7
Use Case Modelling.........................................................................................................................8
Use case Description......................................................................................................................11
References......................................................................................................................................14

2SYSTEMS ANALYSIS AND DESIGN
Introduction
ABC is a Sydney Based university, founded in 2013 where the enrolment of the students
have increased significantly due to high job demands in market. The directors ad chancellor of
the university have decided to develop and information system for online enrolment for the
student (Arkorful & Abaidoo, 2015). This report discusses about the system analysis and system
design of the current business process along with some new features. It also covers the
stakeholder management, actors of the system, use case modelling, functional and non-functional
requirements of the system (Dennis, Wixom & Roth, 2018).
Project Stakeholders
In Project Management, project stakeholders refers to the group, individuals or
organization who may affect or affected by the project, its decisions, activities or results. The
current case study explains about the new enrolment system of ABC University (Johansen, Eik-
Andresen & Ekambaram, 2014). The project comprises multiple stakeholders which can be
categorized into two sub categories of stakeholders based on mode of effects. The directly
affected stakeholders are Pro Vice chancellor, Program directors, Enrolment Officers, Time
Tabling Officers and University itself. On other hand, the students of the university are the
indirectly affected external stakeholders of the project.
a. Pro Vice Chancellor: Pro Vice Chancellor runs the University for the students to learn
and teachers to teach. The idea for providing an online student enrolment system has
been given by the Pro Vice Chancellor.
b. Program Directors: Program director deals with the courses and subjects. First he/she
need to log into the system. The availability of the subjects and already requisite subjects

3SYSTEMS ANALYSIS AND DESIGN
are checked according to the courses. The program director also generate a descripted
status report of the courses and subjects.
c. Enrolment Officer: Enrolment officer deals with the student enrolment of subjects and
courses along with the creation, deletion and editing of the available subjects. To check
the study load of the student, payments and availed subjects, Enrolment officer needs to
log into the system and manage the enrolment. Report generated by the program director
is received by the enrolment officer. The Enrolment officer updates the report by adding
statistics of the enrolment history.
d. University: The University is an existing organization which requires to build the
system. It is the main stakeholder in this project as it is developing and delivering the
system. The increment in the job market has increased and more number of admissions
are happening in the university.
e. Students: Students are the external stakeholders of the project. They are affected by the
result of the project. They can enroll into the university via system and select courses.
Each course can have a set of subjects. The load of the subjects are analyzed by the
enrolment officer based on the subjects. Students are allowed to pay their tuition fees
through the system. The demand in the job market has increased the enrolment of the
students in the university.
f. Time Tabling Officer: Timetabling officer deals with the timetable of the students and
their class according to student course. They can create, edit and remove timetable from
the schedules for any classes and courses.

4SYSTEMS ANALYSIS AND DESIGN
Actors
Actors are referred the users who interacts with the system to perform specific task. The
main goal of the system is to enroll students which is distributed in the objectives tasks. These
tasks are done by several different actors of the system. They play their role in the system and
collaboratively the main goal of the system is achieved (Jacobson, Spence & Kerr, 2016). Each
actor is interacting to the system at least once in the functions. The identification of the actors
can be done by analyzing the business process of the university, individuals who perform certain
tasks and the task in the system. The actors identified for the systems are Time Tabling officer,
Student, enrolment Officer, Program Director, and System itself.
i. System: The system to be developed is supposed to have some functionalities in certain
scenarios. The system is responsible for prompting students for making payments for
their tuition fees. The system is also responsible for generating time table in the system
using input from the time tabling officer along with the email reminders to the student.
ii. Student: The student interact with the system after logging into the system using their
username and authenticated password. Then the student can view the available courses in
the university. Then the availability of the subjects are viewed which are managed by the
program director. Student is allowed to select the courses and make their payment using
secure payment portal in the system. Payment uses the student credit or debit card details
entered by the student in the system. Then the student can receive the generated time
table for his/her classes according to the selected course.
iii. Timetabling Officer: Timetabling officer also requires to log into the system using their
log in credentials. They can create, edit and remove the scheduling of the classes based
on the subjects and courses selected by the students. Each classes can be assigned in

5SYSTEMS ANALYSIS AND DESIGN
multiple campuses of the university and each campuses can have multiple classes on
different subjects.
iv. Enrolment officer: Enrolment officer needs to log into the system before accessing his
functionalities. They can create subjects and course for the new students. The details of
the course and subjects can be edited and removed by the Enrolment officer also.
Enrolment officer also checks the study load upon a student and approves the enrolment.
The enrolment officer generates the report stating the enrolment details campus wise,
course wise an subject wise.
v. Program director: Program director is responsible for maintain the courses in the
system. He/she requires to log into the system to check the availability of courses and
update the results in the system. The availability is checked by considering to total
provided subjects and total requisite subjects. The program director creates a report about
it forwarded to the Enrolment officer for further assessment.
Functional Requirements
System’s Functional requirements is referred to the functions that are required to perform
in the system in order to fulfill the main aim of the development. Different functionalities in a
system can be performed by different actors in the system (Laplante, 2017). The functions are
also called the objectives of the system. The functional requirement of any organization covers
the business processes of the organization which can include, human interaction, calculation and
manipulation of the information (Summers, Joshi & Morkos, 2014). In the current scenario for
ABC University, the system operates manually all the functionalities. The online enrolment
system will cover the same functionalities which will automate and improve the system

6SYSTEMS ANALYSIS AND DESIGN
(Pedrycz, 2018). The functional requirement of the system can be defined from the Unified
Modelling Language technique which are discussed below:
a. The system is supposed allow the student, timetabling officer, program director and
enrolment officer to login into the system using network enabled devices.
b. The system should give the authority to the student to view course and subjects available
in the university.
c. The student should select course and subject available in the university.
d. The system should help the enrolment officer to check the study load of the student based
on the subjects selected by the student.
e. The student should be able to enrolment request to the enrolment officer. The enrolment
will be based on the course and subject.
f. The program director should check the pre-requisite subject and courses. It can be seen
by the students in the student.
g. The program director should be able to update the availability of the subject and course in
the system.
h. The system should prompt the student for the making payment of the student fees.
i. The system should send the email reminder of the events.
j. The system should allow the enrolment officer to create, delete and edit the course and
subjects.
k. The system should generate time table based on the time tabling officer inputs.
l. The system should allow the timetabling officer to create, delete and edit timetable of the
classes for the subjects.
m. The system should be able to store the payment details of the students in the system.

7SYSTEMS ANALYSIS AND DESIGN
n. The system should allow the student to view the time tales of their classes.
o. The system should allow its user to logout from the system.
Non-functional Requirements
Opposite to the functional requirements, functionalities and features of the system does
not depend on the non-functional requirements. Non-functional requirements represents the
quality attributes of the system (Adams, 2015). These are necessary to work in the system so the
system can handle, capacity, performance and scalability related issues. It helps in improving the
functionalities of the system to work better. Some of the standard non-functional requirements
are the performance, reliability, availability, usability, capacity and scalability of the system
(Penzenstadler et al., 2014). In case of the ABC University non-functional requirements are
discussed below:
Performance: The performance of the system should be high. Different function require
different type of processing power, ram and storage resources (Negahban & Smith, 2014). The
system should have the capability to perform all kind of functionalities.
Capacity: The number of the enrolments at an instant may be high for certain time. The system
should handle high amount of requests (Nguyen et al., 2015). The capacity of the system should
high to successfully manage high flow of enrolments.
Availability: The system should be available 24x7 to its users. The user will be able to use the
functionalities of the system anytime. The availability of the system should be consistent.
Usability: The system should be usable for the users. The functions of the system should be easy
to understand to learn by the student. In order to achieve the main of the system, it should have
high usability (Quesenbery, 2014).

8SYSTEMS ANALYSIS AND DESIGN
Security: The system will store important and crucial information of the students, staffs and
university itself (Xu, Wendt & Potkonjak, 2014). The system should have high security
parameters apart from the login system.
Manageability: The system should be able to manage by the admins and by the system itself.
Systems having high manageability does not crash usually.
Scalability: The system should be highly scalable. The inflow and outflow of the information
may get high and low sometimes (McSherry, Isard & Murray, 2015). The scalability should
manage the flow of the system.
Use Case Modelling
Use case modelling is a part of Unified Modelling Language method to identify the use
cases and design use case diagram with the system and actors. The use cases represent the
business process of the system (Evans et al., 2014). It represents the main functionalities of the
system performed by its Actr/User. The below sets of use case diagrams represents
functionalities for different actors of the system.

9SYSTEMS ANALYSIS AND DESIGN
Figure 1: Use Case Diagram for Enrolment Officer
Source: created by author
Figure 2: Use Case Diagram for Timetabling Officer
Source: created by author

10SYSTEMS ANALYSIS AND DESIGN
Figure 3: Use Case Diagram for System
Source: created by author

11SYSTEMS ANALYSIS AND DESIGN
Figure 4: Use Case Diagram for System
Source: created by author
Figure 5: Use Case Diagram for Student
Source: created by author
Use case Description
The selected use cases for the use case description are the make payments and login. Use
case description explains the detail description, path, trigger, and conditions etc. of use cases
individually (Yalla & Sharma, 2014).

12SYSTEMS ANALYSIS AND DESIGN
Use Case Name Payment
ID None
Priority High
Actor Student
Description The use case defines the online payment of the tuition fees by
the student.
Trigger Student enroll for the course.
Precondition Student must exist.
Enrolment officer must approve study load.
Student must select course and subjects.
Normal Course Student interact with the system, selects course, selects
subject and approved by the enrolment officer.
Alternate Course none
Post conditions Payment must be successful.
Student must enroll.
Exception Amount insufficient
Use Case Name Login
ID None
Priority High
Actor Student, program director, Enrolment officer, timetabling
officer.
Description The use case defines the login functionality of the system by

13SYSTEMS ANALYSIS AND DESIGN
its user.
Trigger User enters username and password.
Precondition Users must exist.
Username must be correct.
Password must be correct.
Normal Course User enters username and password to log in.
Alternate Course none
Post conditions Successful login.
Features must be accessible.
Exception Blocked user.

14SYSTEMS ANALYSIS AND DESIGN
References
Adams, K. M. (2015). Nonfunctional requirements in systems analysis and design (Vol. 28).
Cham, Switzerland: Springer international publishing.
Arkorful, V., & Abaidoo, N. (2015). The role of e-learning, advantages and disadvantages of its
adoption in higher education. International Journal of Instructional Technology and
Distance Learning, 12(1), 29-42.
Dennis, A., Wixom, B. H., & Roth, R. M. (2018). Systems analysis and design. John wiley &
sons.
Evans, A., France, R., Lano, K., & Rumpe, B. (2014). Developing the UML as a formal
modelling notation. arXiv preprint arXiv:1409.6928.
Jacobson, I., Spence, I., & Kerr, B. (2016). Use-Case 2.0. Queue, 14(1), 94-123.
Johansen, A., Eik-Andresen, P., & Ekambaram, A. (2014). Stakeholder benefit assessment–
Project success through management of stakeholders. Procedia-Social and Behavioral
Sciences, 119(2), 581-590.
Laplante, P. A. (2017). Requirements engineering for software and systems. CRC Press.
McSherry, F., Isard, M., & Murray, D. G. (2015). Scalability! But at what {COST}?. In 15th
Workshop on Hot Topics in Operating Systems (HotOS {XV}).
Negahban, A., & Smith, J. S. (2014). Simulation for manufacturing system design and operation:
Literature review and analysis. Journal of Manufacturing Systems, 33(2), 241-261.

15SYSTEMS ANALYSIS AND DESIGN
Nguyen, H. V., Xu, C., Ng, S. X., & Hanzo, L. (2015). Near-capacity wireless system design
principles. IEEE Communications Surveys & Tutorials, 17(4), 1806-1833.
Pedrycz, W. (2018). Granular computing: analysis and design of intelligent systems. CRC press.
Penzenstadler, B., Raturi, A., Richardson, D., & Tomlinson, B. (2014). Safety, security, now
sustainability: The nonfunctional requirement for the 21st century. IEEE software, 31(3),
40-47.
Quesenbery, W. (2014). The five dimensions of usability. In Content and complexity (pp. 93-
114). Routledge.
Summers, J. D., Joshi, S., & Morkos, B. (2014, August). Requirements evolution: Relating
functional and non-functional requirement change on student project success. In ASME
2014 International Design Engineering Technical Conferences and Computers and
Information in Engineering Conference. American Society of Mechanical Engineers
Digital Collection.
Xu, T., Wendt, J. B., & Potkonjak, M. (2014, November). Security of IoT systems: Design
challenges and opportunities. In 2014 IEEE/ACM International Conference on
Computer-Aided Design (ICCAD) (pp. 417-423). IEEE.
Yalla, P., & Sharma, N. (2014, March). Parsing natural language text of use case description.
In 2014 Conference on IT in Business, Industry and Government (CSIBIG) (pp. 1-3).
IEEE.