System Requirements Specification
The purpose of this SRS document is to highlight the functional and non-functional requirements of the MathU Similarity Index App.
The MathU Similarity Index App accepts a mathematical problem as user input and returns a list of similar problems. The app provides a confidence score for each problem returned by the algorithm. This confidence score is used to show how similar the returned equation is to the user input. The MathU Learning App also has functionality to solve basic math problems and gives the users access to past papers and memos. The app will be used to help users better understand the problems they are struggling with and how to solve them.
UI - User Interface
API - Application Programming Interface
Memo - Memorandum
App - Application
SRS - System Requirements Specification
There are a finite number of different “types” of problems that students solve as part of their homework exercises. But there are an infinite number of different variations to these problem types. Students are aware of many free software's that are capable of solving these problems and providing an answer, however most of these free software's don’t provide you with the steps to get to that answer. This is where the MathU’s Similarity Index comes in.
Our system should be able to identify from a database a list of similar problems, display a sorted list based on the confidence of our algorithm, where the user can select a problem of their choice and then view the corresponding memorandum. This allows students to see how a similar problem is solved allowing them to improve the efficiency of their studies, and not simply just plagiarise their answers.
Our expected users are students, from primary school through to highschool level. It's not limited to students but the context of the provided solutions will be academic.
2.4.1 The product's efficacy will be closely tied to the expansiveness of the database it has access to, with larger databases being more likely to contain more similar problems.
2.4.2 The system will have to function as a mobile application and as a website, which most likely means there will have to be a background server hosted through some means, that our apps then interface with through an API.
2.4.3 All external libraries & API’s must be open source and free to use.
2.4.4 The indexing of the database must be automatic, no human oversight must be needed for indexing new or existing content.
2.4.5 Use the input dataset provided by MathU.
2.4.6 The input must be a TeX string that matches the content in the provided dataset.
2.4.7 We have until 07 September 2022 to have the final version in release.
We are under the assumption that there exists a database that contains “seen-before” problems with associated memorandums that we can search through for similarities.We also assume that all the answers in the memorandums are correct.
3.1.1 Consume an unseen problem in a search bar, and display a list of similar problems.
3.1.2 User profiles (logging in / signing up)
3.1.3 The results list should be organised based on how similar the problems are to the input (confidence rating).
3.1.4 A user can click a view all problems button to see all the problems in the database.
3.1.5 Search caching, as well as pre-loading for similarities.
3.1.6 Clear search cache and/or preloading.
3.1.7 The system should use Machine learning/AI to assist in the calculation of the similarity indexing.
3.1.8 The system should auto-categorise the problems in its database. These categories could be quadratic equations, differentiation etc.
3.1.9 Filter search results by category optionally.
3.1.10 Admin Page where admin users can manage, upload and remove equations from the database.
3.1.11 If the user searches for a problem that is not in the database, the system should add that problem to the database. (on/off in the admin page)
3.1.12 System should convert between mathML/LaTex to some displayable format.
3.1.13 Users/admins have the ability to attach a link (to a solution online) to a problem that doesn't have an approved solution.
3.1.14 Comments section where users can discuss solutions to problems, interesting similarities etc.
3.1.15 Basic problem solving functionality.
3.1.16 Users can view their search history (Previous Search Queries).
3.1.17 Users can save memos and organise them into folders or groups
3.1.18 Users can switch between light and dark mode
3.2.1 The user wants to find problems similar to one he/she is struggling with, so they would input their problem into the search bar and click search, the system will then display to the user a list of similar problems.
3.2.2 The user would like to sign up or log into their account, functionality to cater for this.
3.2.3 A user wishes to browse through a list of problems (not necessarily sorted) and thus clicks the view all problems button to do so.
3.2.4 The user wants to quickly enter a problem he/she has previously searched for during this session, so when he/she clicks on the search bar it should display all of their previous searches so that they can click on one and it will be auto inputted into the search bar and searched for.
3.2.5 The user would like to see all the problems in the database, this will be displayed to him/her after they click the corresponding button on the home page.
3.2.6 An admin user wishes to increase responsiveness and thus sets the server to preload similarities between all problems, this is done in the admin window.
3.2.7 Also in the admin window, an admin user can turn on or off search caching, (if a problems similarity has not already been calculated and stored, it is stored).
3.2.8 Admins can set when the search cache is automatically cleared, or manually clear it themselves.
3.2.9 A user wishes to filter his search results to only a certain category (eg. Differentiation), using the available options this is done.
3.2.10 An admin user can add unknown problems to the database (they are listed in the admin window) as well as configure auto additions to the database.
3.2.11 Functionality for admins/users to attach links to solutions online, to a problem. (could just be in comments, but preferably have a verified answer system)
3.2.12 A user wants to comment on how difficult a problem is, or ask questions, and is able to do so on each problem.
3.2.13 A user who's logged in wants to save a problem, to their account, that they found useful.
3.2.14 A user has light sensitive eyes and would like to be able to switch between dark mode and light mode, and have this setting "remembered" by the system.
3.2.15 Users would like to be able to see their search history associated with their account, this data should be stored outside of the current session.
3.4.1.1 Search Bar
3.4.1.2 Mathematical visual keyboard
3.4.1.3 Results display list
3.5.1 Search algorithm needs to be performed in a reasonable amount of time.
3.5.2 The confidence rating needs to be an accurate reference for users to see how similar a problem is to theirs.
3.6.1 The fonts we use need to be neat and readable
3.6.2 We need to have our own keyboard that appears when users start typing in the search bar. This keyboard needs to fit neatly on the screen without the user having to scroll horizontally to get the different ends of the keyboard.
3.6.3 Search bar and output fields need to be responsive. Horizontal scrolling will be disabled.
3.6.4 The colour scheme we choose needs to have a good contrast to improve readability.
3.7.1.1 The system needs to be able to work on mobile devices as well as laptops and PCs.
3.7.1.2 The system should work Windows and Android operating systems.
3.7.2.1 User account passwords need to be secured through encryption.
3.7.2.2 Need to protect search bar against SQL Injections.
3.7.3.1 Adding new entries to the database should not produce any breaking errors.
3.7.3.2 The system should be scalable to allow for future implementations.
3.11.1 Search Bar
Pre-conditions:
- Receives a math problem as input in the form of a TeX string.
- Database is populated with numerous math problems.
Post-conditions:
- Returns a list of similar problems found in the database.
- This list is ordered according to a confidence score.
Actor:
- User
Scenario:
- The user enters the problem they wish to find similarities for into the Search Bar, then after pressing the enter key, the app will return a list of problems similar to the entered one.
3.11.2 Confidence Score
Pre-conditions:
- Has some input string.
- Provided with a string from the database.
Post-conditions:
- Returns the evaluation calculated based on the comparison between the input string and the current database string.
Actor:
- AI
Scenario:
- After the user has entered their problem, the system will iterate through all of the problems in the database evaluating their similarity one by one.
3.11.3 History
Pre-conditions:
- The user has previously searched for a problem in this session.
Post-conditions:
- When clicking on the search bar the user should see a list of their previous inputs.
Actor:
- User
Scenario:
- The user has been hard at work searching our database for a variety of problems and now wishes to go back to a result they had previously gotten, upon clicking on the search bar they are presented with a drop down of their previous inputs (stored in cookies/session) and clicking on one of these will auto-fill it into the search bar.
3.11.4 View all problems
Pre-conditions:
- Problems exist in the database
- The user clicks the button.
Post-conditions:
- All the problems in our database are displayed to the user in a neat fashion.
Actor:
- User
Scenario:
- The user wishes to peruse example problems, or manually view the database, they click on the view all problems button, and the system then displays all the information.
- As a mathematics student I want to be able to search a mathematics question so that I can find similar questions which have already have answers. This will help me practice and understand a concept better.
- User can submit the question through the search bar.
- User will receive list of similar questions ranked by confidence score from highest to lowest after successfully entering a query.
- While studying and using our app, as a forgetful student I would like to be able to view all the searches that I've made so I can find the problems I'm looking for again.
- User can view his previous search history via clicking a corresponding button and can save his favorite questions.
- As a student unfamiliar with MathU's similarity index I would like to view the problems stored in the database so I could perhaps see some example problems before searching for what I need.
- User can view all questions in database on request by clicking a button on the home page.
We will be following the decomposition design strategy. We believe that this choice will allow us to look at how each component in our system will interact with one another and to understand how each component will function within the system. This strategy will also make it easier for us to identify important sub-systems, which will allow us to prioritise the development order of these sub-systems. The decomposition design strategy will also allow us to monitor whether we are developing components according to the quality requirements of the system. By having to develop components according to quality requirements, we can better set goals and functions that a component needs to achieve and perform for us to judge the component as working correctly or not.
Because we are developing an interactive system, we will be making use of the N-Tier Architecture style. We will be making use of 3 main layers for this architectural style, namely: the frontend layer, the API layer, and the backend layer. Because of the loose coupling between the layers, the system will be scalable as modifications to one layer should not affect the other layers. It would make sense for us to make use of the Persistence Framework architectural style in our API and backend layers, so that it would be easy for us to manage communication between the API and the databases.
