Non-functional Requirements Question 2022

Name
University
Course
Instructor

Question 1
a. Stakeholders
Pro Vice Chancellor in charge of learning and teaching
Student Enrolment Officer
Program Director
Time tabling officer
b. Actors of the system
Students enrolling in the University
Student Enrolment Officer responsible for enrolment of students
Program Director
Timetabling Officer
Question 2
Functional requirements of a system are the actual tasks that the system is expected to perform
after its implementation (Schmidt et.al; 2014). These requirements are system specific. Every
system has its own functional requirements.
Ten major functional requirements of the system
The functional requirements under the program manager;
1. Login page
2. Course and update registration page.
3. Report generation page
The functional requirements under the student enrolment officer;
4. Login page
5. Course registration page
6. Subject registration page.
7. Study load approval page
8. Report generation page to generate customized reports for instance the total number of
students enrolled in a subject

The functional requirements under the student;
9. Login page.
10. Student registration page
11. View available courses and subjects page
12. Enroll subjects page. Detection of timetable clashes. It should not let students enroll in
too many subjects or fewer subjects unless the study load is approved by the student
enrolment officer
13. Timetable generation page. Generates a timetable customized to each individual student
outlining class times and locations and enable students pay school fees through secure
payment process
14. Mail page. Receive email reminders from system if they have not completed the
enrolment process by a designated deadline.
The functional requirements of the system under the timetabling officer perform the following
tasks;
15. Timetable manipulation’s page. The timetabling officer creates and updates the timetable.

Question 3
Non-functional requirements for the system
Non-functional requirements of a system abbreviated as FURPS, are the requirements of the
system that determine the criteria on how the system should be designed and how it should
operate afterwards (Raturi et.al; 2014). F for functionality of the system, U for usability of the
system, R for reliability of the system, P for performance of the system, and S for security of the
system. These requirements cu across every system that is ever build or developed. Every system
should exhibit these attributes in their operation.
Functionality. This is the ability of a system to perform the tasks and processes it was meant for.
The system should be able to implement all the requirements specified during requirement
specification period of the development (Eckhardt, Vogelsang, and Fernández, 2016). The online
student enrolment system should enable students to enroll subjects and courses, program director
to provide and update relevant courses, the time tabling officer to create and update timetables,
and the student enrolment officer create, edit, and remove courses and subjects. It should enable
all the actors in the system perform their tasks accordingly.
Usability refers to the swiftness of a software to perform its tasks and processes. It also refers to
how easy the system is for users to use (Kurtanović, & Maalej, 2017) The system should be user-
friendly and highly interactive with the users by enabling them achieve several tasks with ease.
The online student enrolment system should enable students to enroll courses in the University
with ease. It should also be easy for new users to learn how to use the system, operate, find
suitable inputs for the system, and expect suitable outputs from the system
Reliability. The system can only be reliable if the users of the system get to trust it. Trust for a
system is gained through a long term use of the system where the users get to experience little or
no inconvenience from the system when performing tasks. A reliable system is one used for a
long period of time without experiencing faults and system failures (Ghezzi, & Sharifloo, 2013).
The online student enrolment system should enroll students successfully under the correct
courses and subjects. The system should not enroll a student in subjects that clash in the
timetable. It should also be accurate and consistent in its operations and task performance.

Performance. The performance of a system is rated with the time the system takes to respond or
perform a given task for the user. it is tested by the number of instructions a system is able to
execute in a second. Systems execute millions of instructions per second. Other attributes that are
useful in measuring performance apart from response time are throughput, transaction rates, and
benchmark considerations (Slankas, & Williams, 2013). For the online student enrolment
system, the response time can be measured in terms of how long the system takes to enroll a
student for a certain course in ABC University or how long the timetabling process done by the
timetabling officer using the system takes.
Security. Refers to the ability of the system to provide safety for the system, data and
information of ABC University. Security is a non-functional requirement which more emphasis
gets laid on during the development of the system by the development team. The security
architecture and the components of the security system are well specified. Security of a system
entails the ability of the system to detect invasion by unauthorized people and programs to the
system and to have defense mechanisms when it comes to attack by malicious persons (Khan
et.al; 2016). Exposed to unsafe environments, the system should not be brought down, it should
activate the defense mechanisms put in place and maintain its daily routine.
Most organizations and institutions implement their systems through the cloud delivery method
of system implementation. Cloud computing ensures the safety of ABC University’s system,
data, files, and information (Carlin, & Curran, 2013). The cloud service providers are solely
responsible for the security of ABC University’s data, files, and information. Cloud service
provision is a business which is very competitive especially when it comes to security provision.
The competition is what keeps the cloud service providers on toes. If a cloud service provider
does not provide enough security, then the clients can migrate to the next service provider.

Question 4
Comprehensive set of Use cases
Student enrolment use case

Course creation and update use case

Study load approval use case

Timetabling use case

Question 5
Use case description for student enrolment use case
Use case Student enrolment
ID 10204
Priority 2
Actor Student
Description 1. A student accesses ABC University website and clicks on the
enroll button
2. The system directs the student to the login form and provides an
option of signing up with the University student portal.
3. The student logs in and clicks on the enroll button
4. The system displays the university enrolment page
5. The student views available courses and subjects, enrolls, and
drops subjects.
6. The system checks whether the subjects enrolled by the student
clash in the timetable.
7. If they clash the system displays “subjects clash in the
timetable” and prompts the student to enroll different subjects
8. If the subjects do not clash in the timetable, the system checks
whether the subjects enrolled are too many or too few.
9. If the subjects are not too many or too few, the system displays
enrolment success.
10. If the subjects are too many or too few, the system checks
whether the student’s study load is approved by the student
enrolment officer.
11. If the study load is approved the system displays enrolment
success and displays a timetable and school fee.
12. The student pays the school fees
13. If the study load is not approved, the system displays not
enrolled message.

Trigger Student wants to enroll for a course in ABC University
Precondition Student accesses ABC University website and clicks the enroll button
Normal course A student logs in to the system, clicks on the course enrolment button,
enters the course enrolment details on the enrolment platform, receives a
timetable, and pays the school fees.
Alternative course
1
1. If the student does not have an account he or she registers by
entering the registration details.
2. The system checks whether the student username exists. If it
exists, the system displays username exists. If it does not exist,
the system displays registration successful.
3. The student is then directed to the login page, logs in and enrolls
Alternative course
2
If the student does not know how to navigate the system or gets errors
doing so, the student enrolment officer enrolls for a course on behalf of
the student.
Post conditions A student has enrolled a course and subjects successfully
Exceptions A student is not registered successfully
A student does not log in successfully
A student terminates the process
Use case description for course creation and update use case
Use case Course creation and update
ID 19780
Priority 1
Actor Program Director, Student enrolment officer
Description A program director logs in to the system and updates the Courses and
subjects offered by ABC University
A student enrolment officer logs in and clicks on course and subject
update button.
The system provides options of course and subject deletion and course
and subject update.

The student enrolment officer chooses either of the platforms depending
on the need
If he or she chooses course and subject deletion, then he or she deletes
the course and subject intended.
If he or she chooses course and subject update, then he or she updates
the course and subject intended.
Trigger A program director wants to provide and update the relevant course and
subject
A student enrolment officer wants to create, edit, and remove courses,
core subjects, and elective subjects offered in each course.
Precondition A program director clicks on course update button
A student enrolment officer clicks on course and subject update button
and clicks on course and subject update button.
Normal Course A program director logs in to the system and Updates the courses and
subjects offered by ABC University.
A student enrolment officer logs in to the system and clicks on the
course and subject update button.
The system provides the student enrolment officer with the platform
through which he or she is able to delete courses and subjects and edit
them whenever he or she deems fit.
The system displays success message for updates.
Alternative Course There is no alternative course to reach the same results
Post conditions Courses, core subjects, and elective subjects are successfully updated
Exception A program director fails to log in to the system
A program director terminates the process
A student enrolment officer fails to log in to the system
A student enrolment officer terminates the process

References
Carlin, S., & Curran, K. (2013). Cloud computing security. In Pervasive and Ubiquitous
Technology Innovations for Ambient Intelligence Environments (pp. 12-17). IGI Global.
Retrieved from https://www.igi-global.com/chapter/cloud-computing-security/68920
Eckhardt, J., Vogelsang, A., & Fernández, D. M. (2016, May). Are" non-functional"
requirements really non-functional? an investigation of non-functional requirements in
practice. In 2016 IEEE/ACM 38th International Conference on Software Engineering
(ICSE) (pp. 832-842). IEEE, Austin.
Ghezzi, C., & Sharifloo, A. M. (2013). Dealing with non-functional requirements for adaptive
systems via dynamic software product-lines. In Software Engineering for Self-Adaptive
Systems II (pp. 191-213). Springer, Berlin, Heidelberg.
Khan, F., Jan, S. R., Tahir, M., Khan, S., & Ullah, F. (2016). Survey: dealing non-functional
requirements at architecture level. VFAST Transactions on Software Engineering, 9(2), 7-
13. Bacha Khan University, Pakistan.
Kurtanović, Z., & Maalej, W. (2017, September). Automatically classifying functional and non-
functional requirements using supervised machine learning. In 2017 IEEE 25th
International Requirements Engineering Conference (RE) (pp. 490-495). IEEE, Lisbon,
Portugal
Raturi, A., Penzenstadler, B., Tomlinson, B., & Richardson, D. (2014, June). Developing a
sustainability non-functional requirements framework. In Proceedings of the 3rd
International Workshop on Green and Sustainable Software (pp. 1-8). ACM.
Schmidt, N., Lüder, A., Steininger, H., & Biffl, S. (2014, September). Analyzing requirements
on software tools according to the functional engineering phase in the technical systems
engineering process. In Proceedings of the 2014 IEEE Emerging Technology and
Factory Automation (ETFA) (pp. 1-8). IEEE, Barcelona, Spain.
Slankas, J., & Williams, L. (2013, May). Automated extraction of non-functional requirements in
available documentation. In 2013 1st International Workshop on Natural Language
Analysis in Software Engineering (NaturaLiSE) (pp. 9-16). IEEE, CA, USA.