Software Requirements Specification
This project is based on the development of a mobile application that will detect and filter SMS spam. The software will be developed inside a computer environment, where an emulator will test its adaptation to the mobile environment. Similar to all software development processes, the development process for this software will be approached with the utmost care and in detail. The development methodology, user characteristics, interface requirements, functional requirements, non-functional requirements, performance requirements, etc… will be clearly presented in this document, along with the necessary use cases that the software is expected to conform to. By preparing the correct software requirements specifications beforehand and creating an efficient work plan, the software development process for the here mentioned spam SMS detection mobile application is expected to follow a fluent and fast moving schedule.
The purpose of our application is to provide a safe and comfortable text messaging experience to our users by detecting and filtering the annoying and threatening spam SMSs that they may receive from unwanted senders. We intend on efficiently using text classification and machine learning techniques to enable our application to perform in a way that promises an accurate detection and filtration of spam SMSs. We have already conducted a thorough research on the previous work done on the spam SMS detection topic and plan on utilizing our deductions from our research as a contribution to the work we are going to carry out in the Software Requirements Specification phase of our project.
The goal of our project is to contribute to the world of telecommunication by developing a spam SMS detection mobile application which mobile phone users will be able to benefit from in means of a much safer and convenient text messaging experience, along with an SMS inbox that is more relevant with respect to their needs and interests. We found out during our previous research that the daily SMS traffic has risen to over 6.9 trillion text messages. This situation, unfortunately, suits the wrongful intentions of SMS spammers. These wrongful intentions can be listed as below:
- The confiscation of the personal/confidential information of mobile phone users is certainly what SMS spammers are mostly eager about. This information includes contact lists, credit card numbers, passwords and etc…
- SMS spammers and keyloggers attempt to obtain the information of their interest by sending spam SMSs that contain viruses or malware that will enable them to hack into mobile phones of their choosing.
- Misleading information, fraud, irrelevant advertisements are also some contents that can be considered as spam SMS.
In addition to the threats imposed by SMS spammers, spam SMS is simply something that is a waste of time for mobile phone users. Spam SMS results in an unclear and irrelevant SMS inbox and is ultimately a nuisance for mobile phone users. With the product that we intend on producing, we hope to get in the way of all the unwanted situations caused by spam SMS and create a much more convenient text messaging environment for our users.
As we’ve stated previously, the spam SMS detection procedure will be carried out with the aid of machine learning. During the course of our research, we looked through many machine learning classifiers that were of potential use for text classification. As a result of our research, we came to the conclusion that we will be using the Naïve Bayes classifier. The Naive Bayes classifier in this project will be implemented in the Python programming language. Text preprocessing, tokenization and feature extraction (with the Bag of Words Model) will also be performed. All of the above tasks will be performed inside the server. Thus, the spam detection service will be provided to the clients(mobile phones) by the server(computer). For the adaption of our development to the mobile environment, we plan on using the React Native tool along with JavaScript.There will be three actors in our project: admin, user and registered user. The admin will have the abilities to list all users, ban/reactivate users of his/her choice from the application and list all of the users that he/she has blocked. For our product, we are giving a great deal of importance to user privacy. Thus, the admin too, will not have access to the SMS inbox of any user. People who are not registered to the application will be know as “users”. Users will be able register to the application via the sign-up function. The final actor in the project is the registered user. Registered users will be able to see all SMSs in their inbox, see spam SMSs in a secondary “spam inbox”, delete any SMS from any inbox, block/unblock senders that they do not want to receive text messages from, see a list of senders that they have blocked, search for SMSs from a specific sender and search for any keyword that might have occurred in any SMS that has been sent by any sender (whether the sender has been blocked or not).
Stakeholders: People contributing to the project.
Python: The programming language for the implementation of the machine learning classifier.
React Native: A tool for mobile development.
MySQL Database: A database that will contain registered users and textual data.
Naïve Bayes: The machine learning classifier of our choice for the text classification process.
Bag of Words: The feature extraction model that will be used in the project.
Admin: The person who supervises the application.
User: Any user that hasn’t been registered to the application.
Registered User: Any user that has been registered to the application.
In this section, we tried to briefly discuss the aim of our project and give an insight on how we plan on approaching the task at hand. We put forward some important definitions that we will mention frequently throughout this document, in the glossary. In the General Overview section, we will talk about our development methodology and the user characteristics. The Software Requirements Specification section will be about external interface requirements(user interfaces, hardware interfaces, etc…), functional requirements, use case diagrams of these functional requirements, non-functional requirements, performance requirements, software system attributes and finally safety requirements. The document comes to an end with our references.
The name of our project is Spam SMS Detection Mobile Application. The end product will filter and detect spam SMSs and place them into a spam inbox. The user will be able to block/unblock senders of his/her choice. Thus, he/she will not receive SMSs from the senders he/she has blocked. Our product will provide a much cleaner and relevant SMS inbox in addition to a safe and efficient text messaging experience.
We will follow a development methodology in which we will start by performing text preprocessing on the raw textual data. We plan on proceeding with tokenization and feature extraction (via the Bag of Words Model). After the text preprocessing, tokenization and feature extraction phases are complete, we will be ready to train our data set with the Naïve Bayes machine learning classifier. The React Native tool will enable us to carry our system to the mobile platform.
The owner of a mobile phone, who is yet to log in to the application (regardless of whether they are registered to the application or not) is a user.
The owner of a mobile phone, who is registered and logged in to the application is a registered user. In order to benefit from the services of the application, one must be registered and logged in.
The admin is the character with the highest privileges in the application. He/she also owns a mobile phone and is also a registered user. He/she will supervise the behavior of all registered users and basically the application as a whole. Additionally, the admin will have the privilege of being able to ban registered users who oppose a threat to either other registered users or the application itself.
User interfaces will be provided for the iOS and Android mobile operating systems.
For the use of our product, a mobile phone that is capable of running the up to date versions of the iOS and Android mobile operating systems is necessary.
- iOS or Android operating system
- SMPP Protocol (Short Message Peer-to-Peer)
- IP protocol (for the communication between the mobile application and the database)
Registered users are required to be receiving services from any mobile network operator in order to be able to use our product.
Use Case:
- Login
- Register
Diagram:
Figure 1: Profile Management Use Case
Brief Description:
Figure 1 shows the main functions performed by the admin, user and the registered user. The admin and users, all need to be registered to the application. Once registered the admin and the registered users will need to log in to the application. The “include” arrow states that one must be registered to the application in order to log in.
Initial Step by Step Description:
1. Initially, the admin must be registered to the application.
2. From then on, “users” who get registered to the application will become “registered users”.
3. The admin will need to log in to the application in order to be able to supervise the registered users, use his/her privileges and benefit from the services of the application.
4. The registered users will need to log in to the application in order to benefit from the services of the application.
Use Case:
- See All SMSs
- See Spam SMSs
- Delete SMSs
- Block Spam Sender
- Unblock Spam Sender
- See Blocked Sender
- Search Contact
- Search Keyword
Diagram:
Figure 2: Main Analysis Use Case
Brief Description:
In Figure 2, the basic operations that can be performed by a registered user can be seen. A registered user has the ability to see all SMSs, see spam SMSs, delete SMSs, block spam senders, unblock spam senders, see blocked senders, search contacts and search keywords.
Initial Step by Step Description:
1. The registered user will be able to see all SMSs via a main inbox
2. Should he/she choose to see the spam SMSs he/she has received, this will also be possible via a secondary inbox in which spam SMSs will be placed by the application
3. The registered user will be able to delete SMSs from both the main inbox and the secondary inbox which contains the spam SMSs.
4. The registered user will have the ability to block a sender from whom he/she does not want to receive text messages from.
5. Step 4 is reversible, meaning that the registered user can unblock a sender that he/she had previously blocked, via the “Unblock Spam Sender” use case.
6. The registered user will be provided the ability to see a list of the senders that he/she has chosen to block.
7. If he/she would like to see the SMSs that have been sent by a certain sender, the registered user will be able to search for that sender via the “Search Sender” use case.
8. Finally, the application includes a “Search Keyword” use case. With this use case, the registered user will be able to search for a certain keyword of his/her choosing among all the SMSs received from all senders.
9. The admin is capable of performing any operation that the registered user can perform.
Use Case:
- Ban Registered User
- Reactivate Registered User
- List All Registered Users
- List All Banned Users
Diagram:
Figure 3: User Management Use Case
Brief Description:
Figure 3 shows the basic operations that can be performed by the admin. The admin is able to list all registered users, ban registered users that oppose a threat to the application or other registered users, list all banned users and reactive a registered user that he/she had previously banned.
Initial Step by Step Description:
1. The admin will have the ability to see a list of all registered users with the “List All Registered Users” use case.
2. If the admin suspects that a certain registered user is opposing a threat to other registered users or the application itself, he/she has the ability to ban that registered user from the application.
3. The admin also has the ability to see a list of the users that he/she had previously banned via the “List All Banned Users” use case.
4. Finally, the admin is capable of reactivating registered users that had been previously banned.
Use Case:
- Update Name
- Update Surname
- Update Phone Number
- Update Email
- Update Password
Diagram:
Figure 4: Personal Information Use Case
Brief Description:
Figure 4 shows the personal information update operations that the admin and registered users can perform. Name, surname, phone number, email and password are the personal information that the admin and registered users are able to update about themselves.
Initial Step by Step Description:
1. When there is a need for update regarding the personal information of the admin (these are name, surname, phone number, email and password), he/she can update this information via the Update Name, Update Surname, Update Phone Number, Update Email and Update Password use cases.
2. Similar to the admin, registered users are also able to update their personal information via the use cases mentioned in step 1.
- A white list that will keep track of words such that, if that word(s) are encountered inside the SMS, the SMS is certainlynot spam.
- Since SMS departure/arrivals occur rapidly, the detection and filtration tasks should be performed rapidly as well.
For optimal performance, mobile phones that are capable of running the up to date versions of the iOS and Android operating systems are recommended. In addition, access to the internet is required.
Also in this section, we would like to mention our success criteria for our spam SMS detection mobile application. We aim to reach a spam detection accuracy of 85%, given that this is an academic project.
This product will be designed for mobile phones. Thus, the only portability that is of our interest is the portability of our product between mobile phones. Our spam SMS detection mobile application will be portable between all mobile phones that are running on either iOS or Android.
- Once inside the application, a user-friendly home page will be shown to the users, where they will be given a choice as to whether they would like to sign up or log in.
- Upon login, the registered user will be shown a menu in which he/she can perform the operations that the application has to offer. (see section 3.2.2 of this report)
- A user interface will be provided to the registered user, where he/she will be able to navigate between the services provided by the application in a clear and understandable way (menus, buttons, colors, etc… will be utilized with the utmost care.
- Once logged in, the registered user will not have to log in every time he/she runs the application (even if he/she has killed the application in the background). This will go on until the registered user chooses to log out of the application.
This product will not necessitate any adaptability requirements.
We will be aiming to see our application on the App Store (for iOS) and the Google Play Store (for Android). Again, access to the internet is an obligation.
We are aware of the increasing work load that may arise for our application, given that the demand for it increases. In such a case, we have some solutions that we can propose:
- Utilizing a bigger server (scaling up) or increasing the number of servers (scaling out)
- Increasing CPU power
- Adding more memory, thus storage to the present one
On the long run, scaling up has a risk of creating bottlenecks between CPU and memory and may not be as preferable as scaling out when the cost-to-benefit ratio is taken into consideration.
As a project team, the safety and privacy of our registered users is of utmost significance to us. Therefore, the SMSs of all registered users, along with the content of these SMSs, will not be visible to any other registered user or even the admin himself/herself. For the most safe and private experience with our application, we will be strictly advising registered users on keeping their passwords to themselves and confidential.
[1] Nagwani, N. K., & Sharaff, A. (2017). SMS spam filtering and thread identification using bi-level text classification and clustering techniques. Journal of Information Science,43(1),75–87.
[2] D. Delvia Arifin, Shaufiah and M. A. Bijaksana, "Enhancing spam detection on mobile phone Short Message Service (SMS) performance using FP-growth and Naive Bayes Classifier," 2016 IEEE Asia Pacific Conference on Wireless and Mobile (APWiMob), Bandung, 2016, pp. 80-84.
[3] Bakliwal, Aditya & Agarwal, Shubhangi & Mehndiratta, Pulkit. (2018). A Comparative Study of Spam SMS Detection Using Machine Learning Classifiers. 1-7.
[4] M. Jameel, Noor. (2018). SMS spam detection using association rule mining based on sms structural features. Journal of Theoretical and Applied Information Technology. 96.
[5] Kaya, Yilmaz. (2018). Spam SMS’lerin filtrelenmesinde yeni bir yaklaşım: Motif örüntüler. Gazi Üniversitesi Fen Bilimleri Dergisi Part C: Tasarım ve Teknoloji. 6. 436-450.
[6] Bäckman, D. (2019). EVALUATION OF MACHINE LEARNING ALGORITHMS FOR SMS SPAM FILTERING (Dissertation).
[7] Pradeep Kumar Roy, Jyoti Prakash Singh, Snehasish Banerjee. (2019). Deep learning to filter SMS Spam. Future Generation Computer Systems. Volume 102. Pages 524-533.
[8] Akshay Divakar, Sitaraa Krishnakumar. (2019). SMS Spam Detection using Tokenization and Feature Engineering. International Journal of Recent Technology and Engineering (IJRTE). Volume-8 Issue-3. Pages 6805-6807.
[9] Tokenize Words and Sentences with NLTK. [Online]. Available: https://www.guru99.com/tokenize-words-sentences-nltk.html.
[10] Sable, M.S., & Kalavadekar, P.N. (2016). SMS Classification Based on Naïve Bayes Classifier and Semi-supervised Learning.
[11] Ham or Spam? SMS Text Classification with Machine Learning. [Online]. Available: https://towardsdatascience.com/sms-text-classification-a51defc2361c.
[12] Popovac, Milivoje & Karanovic, Mirjana & Sladojevic, Srdjan & Arsenovic, Marko & Anderla, Andras. (2018). Convolutional Neural Network Based SMS Spam Detection. 1-4.
[13] Kim, Hwa-Yeon & Lee, Jinsu & Yeo, Na & Astrid, Marcella & Lee, Seung-Ik & Kim, Young-Kil. (2018). CNN based Sentence Classification with Semantic Features using Word Clustering. 484-488.
[14] Achieving Performance, Scalability, and Availability Objectives. [Online]. Available: https://www.oracle.com/technetwork/middleware/coherence/coherence-sample-chapter-132591.pdf.