Magic Maths System

Software Requirements
Specification
for
Magic Maths System

Version 1.0
Prepared by
AINA SARA BINTI MUHAMMADIAH (2022736465)

ALIFF EIRFANN BIN AYUP (2022949911)
AMIRATUN ADLINA BINTI KHAIRUL AMRY (2022996763)
MUHAMMAD NASARUDDIN BIN ABDUL AZIZ (2022786147)
NUR ATHIRAH BINTI NOR AZMAN (2022910349)
SITI NORHANIM BINTI ABDULLAH (2022981825)
18 November 2022
Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for Magic Maths System
Table of Contents
1. Introduction 1
1.1 Purpose 1
1.2 Definitions, Acronyms and Abbreviations 1
1.3 Intended Audience and Reading Suggestions 2
1.4 Product Scope 4
1.5 References 5
2. Overall Description 6
2.1 Product Perspective 6
2.2 Product Functions 6
2.3 User Classes and Characteristics 7
2.4 Operating Environment 7
2.5 Design and Implementation Constraints 7
2.6 User Documentation 8
2.7 Assumptions and Dependencies 8
3. External Interface Requirements 9
3.1 User Interfaces 9
3.2 Hardware Interfaces 9
3.3 Software Interfaces 9
3.4 Communications Interfaces 10
4. System Features (Functional Requirements) 11
5. Other Nonfunctional Requirements 18
5.1 Reliability of the System (NFR_1) 18
5.2 Usability of the Website (NFR_2) 18
5.3. Portability of the System (NFR_3) 18
Appendix A 19
Appendix B 21
Appendix C 23
Appendix D 30
Software Requirements Specification for Magic Maths System
Revision History
Name Date Reason For Changes Version
18/11 Submission 1.0
Software Requirements Specification for Magic Maths System Page 1
1. Introduction
1.1 Purpose
Magic Maths System (MagicMS) was established with the aim to provide a calculator
system for the students in primary school especially in Grade 1, Grade 2, and Grade 3. These
students are usually still depending on their teachers on how to do their homework,
especially on Mathematics subjects. Instead of waiting for their teachers’ answers which
leads to a major time-consuming problem, the students can easily use the MagicMS
anywhere and anytime they need. MagicMS provided many features to ease the students’
flow in accessing our system. For instance, we provide a login page for the students to
access our system efficiently as their details would be saved in the database. Meanwhile for
new users, they need to register first and then when they have their own account they would
be able to log in and access all the goods provided by the MagicMS. Other than that, the
MagicMS is also a tool that students can use to solve mathematical problems without
confusion as for every solution given, there shall be an explanation for it. Once the students
have selected their grade, they will be led up to the exercise page in which they would have
to use the calculator provided by the system. Hence, by deploying this system our team’s
objective will be achieved.
1.2 Definitions, Acronyms and Abbreviations
GPU Graphics Processing Unit 9
GUI Graphical User Interface 3
HDD Hard Disk Drives 9
HTTP Hypertext Transfer Protocol 10
HTML Hypertext Markup Language 8, 10
MacOS Macintosh Operating System 7
MagicMS Magic Maths System 1-5, 10

MB Megabyte 9
MySQL My Structured Query Language 8
NFR Non-functional Requirement 17
PC Personal Computer 8
PHP Hypertext Preprocessor 8
RAM Random-Access Memory 9
SRS Software Requirements Specification 2, 4, 6
XAMPP X-operating system, Apache, MySQL, PHP, Perl 3 7-9
1.3 Intended Audience and Reading Suggestions
While the Software Requirement Specification (SRS) document is written for a more
general audience, this document is intended for individuals directly involved in the
development of Magic Maths System (MagicMS). This includes software developers,
project managers, software designers, software engineers, users, testers and documentation
writers. This project is a prototype for the learning system and it is not restricted within any
premises. It is useful for the educator teams as well as for the students especially students in
Grade 1, Grade 2 and Grade 3. This document need not be read sequentially; users are
encouraged to jump to any section they find relevant. Below is a brief overview of each part
of the document.
● Part 1 (Introduction)
This section offers a summary of the MagicMS project, including purpose
and objectives, project scope, general system details and some major
constraints associated with the intended platform.
● Part 2 (Overall Description)

This section describes the MagicMS class by class, including product
perspective, class hierarchies, operating environment, design and

implementation constraints.
● Part 3 (External Interface Requirements)

This section covers all of the details related to the structure of the Graphical
User Interface (GUI), this includes hardware interfaces, software interfaces
and communications interfaces. Readers can consult this section for a
tentative glimpse of what the final product will look like.
● Part 4 (System Features)

Readers interested in functional requirements of MagicMS should consult
this section as it covers use case specifications and flow patterns utilized by
the system.
● Part 5 (Other Non-Functional Requirements)

This section discusses the non-functional requirements of MagicMS which
are a set of specifications that describe the system’s operation capabilities and
constraints and aim to improve its functionality.
● Part 6 (Appendices)
This section includes any additional information about MagicMS which may
be helpful to readers.
1.4 Product Scope
Primarily, Magic Maths System (MagicMS) is implemented to help students in answering

mathematical problems efficiently. The scope of MagicMS is to simulate a calculator system
for the students at the age of 7, 8 and 9 years old with the intention to ease their calculation
work in mathematical problems.
This SRS is also aimed at specifying requirements of software to be developed and it can
also be applied to assist in the usage of the system. It focuses on the system, the students and
the database itself. The subsystem will handle all of the activities between the student and
the database. Students will be able to access the grade and exercises once registered and
logged in to MagicMS. They will be using the calculator provided to answer each question
hence achieving the system’s objectives which is to provide an efficient calculator system
and encourage students to solve mathematical problems without confusion. As for the
database, it will store the students’ credentials after the registration and authenticate them
every time they log in.
1.5 References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications. IEEE Computer Society, 1998.
2. Overall Description
2.1 Product Perspective
Magic Maths System database and system stores the following information:
User Information
● The user information includes their details such as email and password. This
information is being used to validate the credentials details within the system.
Assessment
● All the information regarding the exercise has been stored within the database for the
user usage. This is to keep track of our grading and exercise in each category.
Answer
● The answer for each of the exercises is in the database to determine whether it is
correct or incorrect, then the system will show the solution and the answer for the
exercise.
2.2 Product Functions
In accordance with the other requirements outlined in this SRS document, the system must,
at a minimum, offer the following features:
● Register a new account

● Log into the website
● Selecting grade
● Selecting exercises
● Answer exercise using calculator
● Submit answers
● Saves user credentials
● Validate user data
● Display exercise
● Save user’s answers
2.3 User Classes and Characteristics
Users of the software system are students between the range of 7-9 years old. The Student is
expected to be Internet literate and capable to perform the functions that are intended for
them to do such as answering questions using the system calculator provided and submitting
answers. The student should be able to perform the following functions:
● Register a new account

● Log into the website
● Selecting grade
● Selecting exercises
● Answer exercise using calculator
● Submit answers
2.4 Operating Environment
The server-side components of the software system must operate within a Windows
operating system or MacOS environment. For Windows, the user must run the system on
Windows 7, Windows 8, Windows 10 or Windows 11.
The system is accessible through every computer, be it laptops or desktop so long as they
conform to the minimum requirements. The system runs smoothly on any web browser such
as Chrome, Firefox, Microsoft Edge, Opera and Safari. The system also works together with
XAMPP to run the database using sql database.
2.5 Design and Implementation Constraints
The information regarding users, assessment and answer has been stored in the database
within the system that is accessible through the website. The XAMPP would be used as the
third party product that acts as a database. As for the user, all they would need is internet
browsing capabilities and internet connection and they would require to put their details to
login into the website.
2.6 User Documentation
The intended audience for user documentation produced regarding the software system is
any software system user. The use of the software system must be explained in a variety of
brief document formats (such as instructions, tutorials, and frequently asked questions) in
HyperText Markup Language (HTML) and/or Portable Document Format (PDF) format.
2.7 Assumptions and Dependencies
Magic Maths System would require a third party product which is XAMPP to store the
database. Before releasing a website to the primary server, XAMPP enables a local host or
server to test its website and clients via desktop and laptop PCs. It is a platform that offers
an appropriate setting for testing and confirming the operation of projects based on Apache,
Perl, MySQL, and PHP through the host's system. Perl is a computer language used for web
development, PHP is a backend scripting language, and MariaDB is the most popular
database created by MySQL among these technologies.
3. External Interface Requirements

3.1 User Interfaces
Login Interface
For new users that have not registered, they can put their details and register. Then, the user
would need to put their details to login which the system would validate the credentials
within the database. If the user has entered the wrong credentials then an error message
occurs.
3.2 Hardware Interfaces
This system will work on every computer, as long as they are on Windows 7 or above. This
system would also work on both laptop or desktop as long as they meet the requirements
that are needed for the system to work perfectly. The table below will show the minimum
and recommended requirements.
Minimum Requirement Recommended Requirement
Processor (CPU) Intel Core i3 (sixth generation Intel Core i5 (sixth generation
or newer) or equivalent or newer) or equivalent
RAM 2-4GB RAM 6GB RAM
Disk Storage HDD with 40 GB and above SDD with 40 GB and above of
of free space free space
Graphics Card (GPU) 512MB 1GB
Operating System Windows 7 Windows 10
3.3 Software Interfaces
In order to run the system, the user must have a dedicated computer. The database is
run by the system in conjunction with “XAMPP”. The operating system on the computer
must be at least Windows 7 or later. The Windows platform can be either 32-bit or 64-bit.
3.4 Communications Interfaces
MagicMS supports all types of web browsers such as Chrome, Firefox, Microsoft
Edge, Opera and Safari as it can run smoothly for the best user experience. The
communication standard, HTTP protocol will be used for this project which is to establish a
connection with the server and send HTML pages back to the user's browser.
4. System Features (Functional Requirements)

4.1 Use case name Register student
4.1.1 Description When the registrar wants to use the system, they will need
to register themselves by keying in their email and
password. When it is successfully registered, the data will
be saved into the database and the registrar will have their
own account to log in to the website.
4.1.2 Pre-Condition(s) The student has no existing account.
4.1.3 Post-Condition(s) The student is successfully registered to the website.
4.1.4 Actor Student
4.1.5 Flow of Events
4.1.5.1 Primary Flow 1. The registrar enters their email and password to create
an account.
2. The registrar presses the sign up button to be able to
3. The system saves and records users’ data.
4.1.5.2 Alternative Flow 1. The registrar enters their email and password to create
an account.
3. The system displays an error message because the user
has entered invalid credentials
4. The registrar re-enters credentials.
4.1.5.3 Exception Flow 1. If the user aborts the use case, the system returns the
user to the homepage without the user being logged in and
any information has been erased.
2. The system is unable to connect to the database after
the registrar has entered their credentials. Use case ends
4.2 Use case name Login student
4.2.1 Description Students who already have an account, they will need to
login the system by entering their email and password that
has been setup during their registration process.
4.2.2 Pre-Condition(s) 1. The student has an account

2. The student is not already logged in to the website.
4.2.3 Post-Condition(s) 1. The student will be able to login with a valid email and
password.
2. The student will have access to the functions of the
website.
4.2.4 Actor Student
4.2.5.1 Primary Flow 1. The student enters their email and password.
2. The student presses the login button.
3. The system searches the student’s record in the
database.
4. The database will check and validate the user
information.
5. Once validated, the student will be able to access the
website.
4.2.5.2 Alternative Flow If the student inputs an incorrect credential, the system
pauses this use case, prompting the user to re-enter the
correct credential. If the user aborts the use case, the use
case ends.
4.2.5.3 Exception Flow 1. If the student inputs the credentials that are not in the
database, the user will be prompted to create a new
account.
2. The system is unable to connect to the database, use
case ends
4.3 Use case name Select grade
4.3.1 Description Students need to select the “Grade” option before they
start their learning and exercise sessions. This is to ensure
that they learn the topics based on their range of syllabus.
4.3.2 Pre-Condition(s) The student has logged on to the website.
4.3.3 Post-Condition(s) A grade has been selected and the website directed to the
exercise page.
4.3.4 Actor Student

4.3.5.1 Primary Flow 1. The student shall choose their grade first to be able to
access the exercises.
2. The system will show the grade chosen and its available
exercises.
4.3.5.2 Alternative Flow Not applicable
4.3.5.3 Exception Flow If the student aborts the use case, the system will not show
the grade chosen and its available exercises, and the use
case ends.
4.4 Use case name Select exercise
4.4.1 Description Students need to select the “Exercise” option before they
that they choose which subtopic that they are interested in.
4.4.2 Pre-Condition(s) The students have selected a grade.
4.4.3 Post-Condition(s) 1. An exercise has been selected and the website directed
to the exercise page.
2. The exercise page is displayed.
4.4.4 Actor Student
4.4.5.1 Basic Flow 1. The student needs to select the exercises based on the
subtopics displayed.
2. The subsystem then shall display the exercise chosen by
the student.
4.4.5.3 Exception Flow If the student aborts the use case, the system will not
display the available exercises and the use case ends.
4.5 Use case name Answer exercise
4.5.1 Description An example for each of the subtopics will be provided by

the system. Students need to answer the questions that
have been prepared. This is to ensure that they learn the
topic and understand them well.
4.5.2 Pre-Condition(s) 1. The students have selected a grade.

2. The students have opened the exercise.
4.5.3 Post-Condition(s) An exercise was displayed and the answer by the student
was recorded by the website.
4.5.4 Actor Student
4.5.5.1 Primary Flow 1. The student needs to answer the exercise provided by
the subsystem.
4.5.5.3 Exception Flow If the student aborts the use case, the use case ends.
4.6 Use case name Submit answer
4.6.1 Description Students need to submit their answers after the learning
and answering session. The result of their questionnaire
will appear after they answer the questions.
43.6.2 Pre-Condition(s) The students have answered at least one question from the
exercise.
4.6.3 Post-Condition(s) 1.The student can submit the exercise and check the
answer.
2. The solution to each question will be displayed.
4.6.4 Actor Student
4.6.5.1 Primary Flow 1. Once answered, the student needs to submit it by

pressing the submit button.
2. The system will save the answer after the submission.
3. Once saved, the system will check the answer whether
it is correct or incorrect.
4. Either way, the system will display the answer and
explanation for the student.
4.6.5.3 Exception Flow 1. If the student aborts the use case, the system will not
save the answer into the database and the use case ends.
2. The database is not accessible and the data could not be

saved.
4.7 Use case name Proceed to the Next Question?
4.7.1 Description Students can choose whether they want to proceed to the
next question or move to another subtopic that they are
interested in.
4.7.2 Pre-Condition(s) The user has click the proceed button
4.7.3 Post-Condition(s) It turns to the next page.
4.7.4 Actor Student
4.7.5.1 Primary Flow 1. The student will be given a choice to proceed to the
next exercise or not. If the student chooses yes, the student
will proceed to the next question.
2. If the student chooses no, then the session will end.
4.8 Use case name Saves Credentials
4.8.1 Description Students’ credentials will be saved after they have

registered. This action also will help the admin/staff to
view the number of their students who use the system.
4.8.2 Pre-Condition(s) A data have been saved
4.8.3 Post-Condition(s) The data have been recorded by the system.
4.8.4 Actor Primary actor: Database

- Student
4.8.5.1 Primary Flow 1. Once the student has registered, the credentials will be
saved in the database.
4.8.5.3 Exception Flow The system is unable to save the credentials as the
database is not accessible. The system warns the user
about the problem and the data could not be saved.
4.9 Use case name Validation
4.9.1 Description Validation process will be done when the student wants to
log in to the system. If the credentials are correct and
equivalent to the database, it will be redirected to the main
page.
4.9.2 Pre-Condition(s) A validation have submitted
4.9.3 Post-Condition(s) 1.The action is completed

2. If something fails, the action will not be performed.
4.9.4 Actor - Primary actor: Database

- Student
4.9.5.1 Primary Flow 1. Once the student has logged in, the system will validate
whether the student’s credentials are correct or incorrect.
2. If the input is incorrect, the student must try to log in
again.
3. If the input is equivalent to the one in the database, the
student will be redirected to the next step.
4.9.5.3 Exception Flow The system cannot validate the account credentials. The
system warns the user about the problem and the screen
returns to the main Login screen.
4.10 Use case name Use Calculator
4.10.1 Description Students need to answer the exercise given using the
calculator provided as to give them exposure on how to
use a calculator when answering mathematical questions.
4.10.2 Pre-Condition(s) Students must input their answer in the calculator.

4.10.3 Post-Condition(s) The answer in the calculator shall be submitted and saved
in the system.
4.10.4 Actor - Student
4.10.5.1 Primary Flow 1. Once the student wants to answer the exercise, they
have to use the calculator provided.
2. The student needs to input the answer in the calculator
by clicking the buttons on the calculator for the system to
calculate.
4.10.5.3 Exception Flow The calculator is not displayed to the user.

5. Other Nonfunctional Requirements

5.1 Reliability of the System (NFR_1)
The likelihood that a system operates well for a given period of time is known as reliability.
The reliability decreases as more time is taken into account for reliability calculations
because it obeys the exponential failure law. In other words, a system's reliability will
initially be high and gradually decline to its lowest level over time. This requirement is
meant to identify whether the software can work without any failure for a given period. The
database must be updated when new data has been inserted.
5.2 Usability of the Website (NFR_2)
Usability is a product's ease of use. Almost anything can be the object, including a device,
instrument, method, publication, piece of software, or website. Anything that may be used
by a person should be usable. The ease with which the average person can use software or
websites to accomplish particular goals has been defined as usability in the context of
websites and software applications. For these requirements, it is to identify user’s difficulty
in learning/using or operating the system provided by the developer. It also will be a simple
design which can lead to website-friendly for visitors as we create this system for children
who range between 7 years old to 9 years old.
5.3. Portability of the System (NFR_3)
A computer programme is said to be portable if it can run on an operating system other than
the one it was designed for without requiring extensive rewriting. The process of making a
computer programme run in a new environment is known as porting. In this case, it will
specify the conditions under which a system can be started. The system also will gauge how
well users are adapting to the system and how simple it is for them to learn and use. This
system also will establish whether a system or one of its parts can be started in a specific
situation.
Appendix A: Approval
The undersigned acknowledge they have reviewed the Magic Maths System Software
Requirements Specification and agree with the approach it presents. Changes to this Software
Requirements Specification will be coordinated with and approved by the undersigned or their
designated representatives.
1. Signature: Date: 17 Nov 2022

Name: Amiratun Adlina binti Khairul Amry
Student ID: 2022996763
Role: Team Leader

Name: Aina Sara binti Muhammadiah
Role: Software Requirement Analyst

Name: Nur Athirah binti Nor Azman
Role: Software Designer
4. Signature : Date: 17 Nov 2022

Name: Siti Norhanim binti Abdullah
Role: Software Tester

Name: Muhammad Nasaruddin bin Abdul Aziz
Role: Software Developer

Name: Aliff Eirfann bin Ayup
Role: Software Engineer
Appendix B: Glossary
Graphics Processing Unit (GPU) is a specialized electronic circuit designed to manipulate and
alter memory to accelerate the creation of images in a frame buffer intended for output to a display
device.
Graphical User Interface (GUI) is a form of user interface that allows users to interact with
electronic devices through graphical icons and audio indicators such as primary notation, instead of
text-based UIs, typed command labels or text navigation.
Hard Disk Drives (HDD) is an electro-mechanical data storage device that stores and retrieves
digital data using magnetic storage with one or more rigid rapidly rotating platters coated with
magnetic material.
Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite
model for distributed, collaborative, hypermedia information systems.
Hypertext Markup Language (HTML) is the standard markup language for documents designed
to be displayed in a web browser. It can be assisted by technologies such as Cascading Style Sheets
and scripting languages such as JavaScript
Macintosh Operating System (MacOS) developed by Apple Inc. includes the graphical user
interface-based operating systems it has designed for use with its Mac series of personal computers
since 1984, as well as the related system software it once created for compatible third-party
systems.
Magic Maths System (MagicMS) is implemented to help students in answering mathematical

problems efficiently. The subsystem will handle all of the activities between the student and the
database.
Megabyte (MB) is a multiple of the unit byte for digital information. Its recommended unit symbol
is MB. The unit prefix mega is a multiplier of 1000000 (106) in the International System of Units
(SI).
My Structured Query Language (MySQL) is an open-source relational database management

system. Its name is a combination of "My", the name of co-founder Michael Widenius's daughter
My, and "SQL", the abbreviation for Structured Query Language.
Non-functional Requirement (NFR) is a requirement that specifies criteria that can be used to
judge the operation of a system, rather than specific behaviors.
PHP Hypertext Preprocessor (PHP) is a general-purpose scripting language geared toward web
development. It was originally created by Danish-Canadian programmer Rasmus Lerdorf in 1993
and released in 1995.
Random-Access Memory (RAM) is a form of computer memory that can be read and changed in
any order, typically used to store working data and machine code. A random-access memory device
allows data items to be read or written.
Software Requirements Specification (SRS) is a description of a software system to be developed.

It is modeled after business requirements specification (CONOPS). The software requirements
specification lays out functional and non-functional requirements, and it may include a set of use
cases that describe user interactions that the software must provide to the user for perfect
interaction.
X-operating system, Apache, MySQL, PHP, Perl 3 (XAMPP) is a free and open-source
cross-platform web server solution stack package developed by Apache Friends,[2] consisting
mainly of the Apache HTTP Server, MariaDB database, and interpreters for scripts written in the
PHP and Perl programming languages.
Appendix C: Use Case Descriptions
● Use case name: Unique name that represents the goal of the use case
● Description: It describes the outcomes of an action taken to accomplish a specific goal
● Pre-condition: The condition that must hold for the use case to begin
● Post condition: The conditions that must hold once the use case has completed
● Actor: Any person or system external to the system that uses or interacts with that system to
achieve a goal. Each actor is given a role to represent their interactions with the solution
● Flow of Events: The set of steps that must be taken by the actor and the solution while the
use case is being performed
● Primary Flow: An actor that initiates a use case.
● Alternative Flow: The inputs from the actors and system responses that represent other less
common paths to accomplish the actor’s goal
● Exception Flow: The inputs from the actors and system responses that represent an
unsuccessful path when the actor’s goal is unachievable.
4.1 Use case name Register student
4.1.1 Description When the registrar wants to use the system, they will need
to register themselves by keying in their email and
password. When it is successfully registered, the data will
be saved into the database and the registrar will have their
own account to log in to the website.
4.1.2 Pre-Condition(s) The student has no existing account.
4.1.3 Post-Condition(s) The student is successfully registered to the website.
4.1.4 Actor Student
4.1.5.1 Primary Flow 1. The registrar enters their email and password to create
an account.
3. The system saves and records users’ data.
4.1.5.2 Alternative Flow 1. The registrar enters their email and password to create
an account.
3. The system displays an error message because the user
has entered invalid credentials
4. The registrar re-enters credentials.
4.1.5.3 Exception Flow 1. If the user aborts the use case, the system returns the
user to the homepage without the user being logged in and
any information has been erased.
2. The system is unable to connect to the database after
the registrar has entered their credentials. Use case ends
4.2 Use case name Login student
4.2.1 Description Students who already have an account, they will need to
login the system by entering their email and password that
has been setup during their registration process.
4.2.2 Pre-Condition(s) 1. The student has an account

2. The student is not already logged in to the website.
4.2.3 Post-Condition(s) 1. The student will be able to login with a valid email and
password.
2. The student will have access to the functions of the
website.
4.2.4 Actor Student
4.2.5.1 Primary Flow 1. The student enters their email and password.
2. The student presses the login button.
3. The system searches the student’s record in the
database.
4. The database will check and validate the user
information.
5. Once validated, the student will be able to access the
website.
4.2.5.2 Alternative Flow If the student inputs an incorrect credential, the system
pauses this use case, prompting the user to re-enter the
correct credential. If the user aborts the use case, the use
case ends.
4.2.5.3 Exception Flow 1. If the student inputs the credentials that are not in the
database, the user will be prompted to create a new
account.
2. The system is unable to connect to the database, use
case ends
4.3 Use case name Select grade
4.3.1 Description Students need to select the “Grade” option before they
that they learn the topics based on their range of syllabus.
4.3.2 Pre-Condition(s) The student has logged on to the website.
4.3.3 Post-Condition(s) A grade has been selected and the website directed to the
exercise page.
4.3.4 Actor Student
4.3.5.1 Primary Flow 1. The student shall choose their grade first to be able to
access the exercises.
2. The system will show the grade chosen and its available
exercises.
4.3.5.3 Exception Flow If the student aborts the use case, the system will not show
the grade chosen and its available exercises, and the use
case ends.
4.4 Use case name Select exercise
4.4.1 Description Students need to select the “Exercise” option before they
that they choose which subtopic that they are interested in.
4.4.2 Pre-Condition(s) The students have selected a grade.
4.4.3 Post-Condition(s) 1. An exercise has been selected and the website directed
to the exercise page.
2. The exercise page is displayed.
4.4.4 Actor Student
4.4.5.1 Basic Flow 1. The student needs to select the exercises based on the
subtopics displayed.
2. The subsystem then shall display the exercise chosen by
the student.
4.4.5.3 Exception Flow If the student aborts the use case, the system will not
display the available exercises and the use case ends.
4.5 Use case name Answer exercise
4.5.1 Description An example for each of the subtopics will be provided by

the system. Students need to answer the questions that
have been prepared. This is to ensure that they learn the
topic and understand them well.
4.5.2 Pre-Condition(s) 1. The students have selected a grade.

2. The students have opened the exercise.
4.5.3 Post-Condition(s) An exercise was displayed and the answer by the student
was recorded by the website.
4.5.4 Actor Student
4.5.5.1 Primary Flow 1. The student needs to answer the exercise provided by
the subsystem.
4.6 Use case name Submit answer
4.6.1 Description Students need to submit their answers after the learning
and answering session. The result of their questionnaire
will appear after they answer the questions.
43.6.2 Pre-Condition(s) The students have answered at least one question from the
exercise.
4.6.3 Post-Condition(s) 1.The student can submit the exercise and check the
answer.
2. The solution to each question will be displayed.
4.6.4 Actor Student
4.6.5.1 Primary Flow 1. Once answered, the student needs to submit it by

pressing the submit button.
2. The system will save the answer after the submission.
3. Once saved, the system will check the answer whether
it is correct or incorrect.
4. Either way, the system will display the answer and
explanation for the student.
4.6.5.3 Exception Flow 1. If the student aborts the use case, the system will not
save the answer into the database and the use case ends.
2. The database is not accessible and the data could not be
saved.
4.7 Use case name Proceed to the Next Question?
4.7.1 Description Students can choose whether they want to proceed to the
next question or move to another subtopic that they are
interested in.
4.7.2 Pre-Condition(s) The user has click the proceed button
4.7.3 Post-Condition(s) It turns to the next page.
4.7.4 Actor Student
4.7.5.1 Primary Flow 1. The student will be given a choice to proceed to the
next exercise or not. If the student chooses yes, the student
will proceed to the next question.
2. If the student chooses no, then the session will end.

4.8 Use case name Saves Credentials
4.8.1 Description Students’ credentials will be saved after they have

registered. This action also will help the admin/staff to
view the number of their students who use the system.
4.8.2 Pre-Condition(s) A data have been saved
4.8.3 Post-Condition(s) The data have been recorded by the system.
4.8.4 Actor Primary actor: Database

- Student
4.8.5.1 Primary Flow 1. Once the student has registered, the credentials will be
saved in the database.
4.8.5.3 Exception Flow The system is unable to save the credentials as the
database is not accessible. The system warns the user
about the problem and the data could not be saved.
4.9 Use case name Validation
4.9.1 Description Validation process will be done when the student wants to
log in to the system. If the credentials are correct and
equivalent to the database, it will be redirected to the main
page.
4.9.2 Pre-Condition(s) A validation have submitted
4.9.3 Post-Condition(s) 1.The action is completed

2. If something fails, the action will not be performed.
4.9.4 Actor - Primary actor: Database

- Student
4.9.5.1 Primary Flow 1. Once the student has logged in, the system will validate
whether the student’s credentials are correct or incorrect.

2. If the input is incorrect, the student must try to log in
again.
3. If the input is equivalent to the one in the database, the
student will be redirected to the next step.
4.9.5.3 Exception Flow The system cannot validate the account credentials. The
system warns the user about the problem and the screen
returns to the main Login screen.
4.10 Use case name Use Calculator
4.10.1 Description Students need to answer the exercise given using the
calculator provided as to give them exposure on how to
use a calculator when answering mathematical questions.
4.10.2 Pre-Condition(s) Students must input their answer in the calculator.
4.10.3 Post-Condition(s) The answer in the calculator shall be submitted and saved
in the system.
4.10.4 Actor - Student
4.10.5.1 Primary Flow 1. Once the student wants to answer the exercise, they
have to use the calculator provided.
2. The student needs to input the answer in the calculator
by clicking the buttons on the calculator for the system to
calculate.
4.10.5.3 Exception Flow The calculator is not displayed to the user.

Appendix D: Analysis Models
Activity Diagram
Sequence Diagrams
Sequence diagram for Register and Login

Sequence diagram for Choose Grade and Answer Exercise

Sequence diagram for Submit Answer and Proceed To Next Question

Magic Maths System - Srs-Ieee

Uploaded by

Document Information

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

Magic Maths System - Srs-Ieee

Uploaded by

Copyright:

Available Formats

Software Requirements

AINA SARA BINTI MUHAMMADIAH (2022736465)

1.2 Definitions, Acronyms and Abbreviations

GPU Graphics Processing Unit 9

GUI Graphical User Interface 3

HDD Hard Disk Drives 9

HTTP Hypertext Transfer Protocol 10

HTML Hypertext Markup Language 8, 10

MacOS Macintosh Operating System 7

MagicMS Magic Maths System 1-5, 10

MySQL My Structured Query Language 8

NFR Non-functional Requirement 17

PHP Hypertext Preprocessor 8

RAM Random-Access Memory 9

SRS Software Requirements Specification 2, 4, 6

XAMPP X-operating system, Apache, MySQL, PHP, Perl 3 7-9

1.3 Intended Audience and Reading Suggestions

● Part 2 (Overall Description)

perspective, class hierarchies, operating environment, design and

● Part 3 (External Interface Requirements)

● Part 4 (System Features)

● Part 5 (Other Non-Functional Requirements)

1.4 Product Scope

Primarily, Magic Maths System (MagicMS) is implemented to help students in answering

2.2 Product Functions

● Register a new account

2.3 User Classes and Characteristics

● Register a new account

2.4 Operating Environment

2.5 Design and Implementation Constraints

2.6 User Documentation

2.7 Assumptions and Dependencies

3. External Interface Requirements

3.2 Hardware Interfaces

Minimum Requirement Recommended Requirement

RAM 2-4GB RAM 6GB RAM

Graphics Card (GPU) 512MB 1GB

Operating System Windows 7 Windows 10

3.3 Software Interfaces

3.4 Communications Interfaces

4. System Features (Functional Requirements)

4.1.2 Pre-Condition(s) The student has no existing account.

4.1.3 Post-Condition(s) The student is successfully registered to the website.

4.1.4 Actor Student

4.1.5 Flow of Events

4.2 Use case name Login student

4.2.2 Pre-Condition(s) 1. The student has an account

2. The student is not already logged in to the website.

4.2.4 Actor Student

4.2.5 Flow of Events

4.3 Use case name Select grade

4.3.2 Pre-Condition(s) The student has logged on to the website.

4.3.4 Actor Student

4.3.5 Flow of Events

4.3.5.2 Alternative Flow Not applicable

4.4 Use case name Select exercise

4.4.2 Pre-Condition(s) The students have selected a grade.

4.4.4 Actor Student

4.4.5 Flow of Events

4.4.5.2 Alternative Flow Not applicable

4.5 Use case name Answer exercise

4.5.1 Description An example for each of the subtopics will be provided by