Department of Information Technology
Contents and Format of Major Project Report
Guidelines for Major Project Report:
General Report Format
1.
Use A4 size paper.
2.
Font should be Times New Roman
3.
Main heading
3.1
Should be in capitals.
3.2
Font size 14
3.3
Should be bold.
4. Sub heading
4.1 First character should be capital.
4.2
Font size 12
4.3 Should be bold.
5. Content must be justified.
6. Line spacing
6.1 Line spacing between heading and paragraph should be 1.5.
6.2 For Content Line spacing should be 1.5.
7. Page numbers at the Bottom –Middle part of the page.
7.1 From Introduction use number (1, 2 ,3 …...)
7.2 Front Page should not contain page number, but After Front page,the number should be start
which is in roman number i.e. (i,ii,….)
8. Report Binding
8.1 Report should be Spiral binded.
8.2 Only one copy is required for all group member.
1

for
Submitted To : Submitted By :
Name: Dinesh Bhayal Name:Adiba Khan(0876IT151002)
Designation: Project Guide Name : Gurleen KaurJudge ( 0876IT151018 )
Department of Information Technology
November, 2018
2

for
Internal Examiner External Examiner
Name: Dinesh Bhayal
Designation : Project Guide
Department of Information Technology
November, 2018
3

4

Table of Contents .......................................................................................................................... ii
List of Figures .............................................................................................................................. iii
List of Tables …………………………………………………………………………………….iv
1.
Introduction .............................................................................................................................. 1
1.1 Purpose ......................................................................................................................................... 1
1.2 Document Conventions ..................................................................................................................
1.3 Intended Audience and Reading Suggestions .................................................................................
1.4 Product Scope .................................................................................................................................
1.5 References ......................................................................................................................................
2.
Overall Description ....................................................................................................................
2.1 Product Perspective ........................................................................................................................
2.2 Product Functions ...........................................................................................................................
2.3 User Classes and Characteristics ....................................................................................................
2.4 Operating Environment ..................................................................................................................
2.5 Design and Implementation Constraints .........................................................................................
2.6 User Documentation .......................................................................................................................
2.7 Assumptions and Dependencies .....................................................................................................
3.
External Interface Requirements .............................................................................................
3.1 User Interfaces ................................................................................................................................
3.2 Hardware Interfaces ........................................................................................................................
3.3 Software Interfaces .........................................................................................................................
3.4 Communications Interfaces ............................................................................................................
4.
System Features .........................................................................................................................
4.1 System Feature 1 ............................................................................................................................
4.2 System Feature 2 (and so on) ..........................................................................................................
5.
Other Nonfunctional Requirements .........................................................................................
5.1 Performance Requirements .............................................................................................................
5.2 Safety Requirements .......................................................................................................................
5.3 Security Requirements ....................................................................................................................
5.4 Software Quality Attributes ............................................................................................................
5.5 Business Rules ................................................................................................................................
6.
Other Requirements ..................................................................................................................
Appendix A: Glossary .....................................................................................................................
Appendix B: Analysis Models .........................................................................................................
Appendix C: To Be Determined List .............................................................................................
5

Figure No.
1
LIST OF FIGURES
Figure Name
ER- Diagram
6
Page No.
2

Table No.
1
LIST OF TABLES
Table Name
Data Dictionary
7
Page No.
2

API
Big Data
Cold Start
IEEE
OS
1.
1.1
Purpose
This document provides a detailed description of Software Requirements Specification
(SRS) for Recommendation System. It is prepared according to “IEEE Recommended
Statements for Software Requirements Specification - IEEE Standard 830 – 1998”.
The Software Requirements Specification (SRS) document is intended to provide the requirements of the Recommender System project and the expectations of the stakeholders.
The document includes the project perspective, data model and constraints of the overall system.
The intended audiences of the document are project managers, developers, testers and end users.
· Project managers review the document and determine whether the planned system fulfills the requirements. They notify the developers to fill up missing parts.
· Developers provide consistency by using the documentation.
· Testers use the documentation for verification and validation.
. End users make use of this document to learn about the scope of the system and its capabilities.
1.2
Document Conventions
Term Description
Application Programming Interface
A collection of data sets so large and complex that it becomes difficult to process using on- hand database management tools or traditional data processing applications
The issue that the system cannot draw any inferences for users or items about which it not yet gathered sufficient information
The Institute of Electrical and Electronical
Engineers
Operating system
8

RMSE
UML
Web Service
UI
Root Mean Square Error
Unified Model Language
A software function provided at a network address over the web or the cloud
Ueer Interface
1.3
Intended Audience and Reading Suggestions
The intended audiences of the document are project managers, developers, testers and end users.
· Project managers review the document and determine whether the planned system fulfills the requirements. They notify the developers to fill up missing parts.
· Developers provide consistency by using the documentation.
· Testers use the documentation for verification and validation.
. End users make use of this document to learn about the scope of the system and its capabilities.
1.4
Product Scope
The targeted software product is a Recommendation System. The system makes an extensive use of user data to come up with reasonable track predictions about user preferences and there are two main paradigms in this sense: Content-based and collaborative filtering. As a beginning, the scope of the system is scaled down to collaborative filtering. This type of filtering is based on collecting and analyzing huge amount of user information; users’ behaviors, activities, preferences and similarities to other users. The scope consists of determining similar users according to the similarities between their evaluations of certain track attributes. The system is aimed to have additional solutions for big data and sparse information. The test data will be provided from Argedor. The test data for the system are planned to contain millions of users and irregular data such that some user-track relation remains unknown. The project limits the improvement of the recommendation system around these challenges and favors accuracy over performance while giving the final suggestions. As a milestone, the system should follow the methods to enhance accuracy, the performance enhancements are not included in the scope.
The Recommender System will be a Web Service and the end users will be directly exposed to
9

the suggestions made for them .
1.5
References
[1] Herlocker, J. L., Konstan, J. A., Terveen, L. G., & Riedl, J. T. (2004). Evaluating
Collaborative Filtering Recommender Systems. ACM Transactions on Information Systems,
22(1), 5-53. doi:10.1145/963770.963772
[2] IBM. (n.d.). Portability and Interoperability. Retrieved October 27, 2013, from http://www.ibm.com/developerworks/webservices/library/ws-port/
[3] IEEE. (1998). IEEE Std 830-1998 IEEE Recommended Practice for Software
Requirements
Specifications. IEEE Computer Society.
[4] Rubens, N., Kaplan, D., & Sugiyama, M. (2011). Active Learning in Recommender
Systems.
In P. B. Kantor, F. Ricci, L. Rokach & B. Shapira (Eds.), Recommender Systems Handbook
(pp.
735-767). New York, USA: Springer.
[5] Sparx Systems. (2000). UML 2 Tutorial. Retrieved October 26, 2013, from http://www.sparxsystems.com/resources/uml2_tutorial/
[6] Peter Neubauer.(2009). Neo4j vs Hadoop. Retrieved October 27, 2013, from http://lists.neo4j.org/pipermail/user/2009-April/001118.htmlOverall Description
1.6
Product Perspective
Recommendation system is a software tool that provides suggestions for items to a user.
Our recommendation system is a component of a larger system which is a music streaming and downloading web application. The application integrates our system to main web application as a web service. Web services extend the World Wide Web infrastructure to provide the means for software to connect to other software applications. Our web service helps existing larger system to increase in usage of system by accurate suggestions. Moreover, this web service is free and open source with a GNU General Public License (GPL).
Music downloading and listening service is supported by Argedor. This service provides users with the legal right of accessing music files. It also enables the users to download music in mp3 format in case of purchasing music packages. The service provides the opportunity of displaying latest news and music lists along with going over the lyrics and album information.
Moreover, there are two types of track lists, professional lists provided by application and user lists created by individual user. Users can display both two types of lists. All these actions generate dataset to our system for accurate recommendations based on users' and items' similarities. ARGEDOR -supporter company- acts like an interagent between users and our recommendation system. The dataset is the most important part of our system therefore main system's existence and wide usage are important for generating recommendations on our system.
The external interface and the interconnection between the large system and the Recommender
System can be seen in Figure 1.
10

Figure 1: Block diagram
1.7
Product Functions
Recommendation System is composed of the following fundamental features:
Users:
Generate Data
Get Recommendation
Interagent:
Get Recommendation
Provide Dataset
Update Dataset
Integrate Web Service
1.8
User Classes and Characteristics
<Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the most important user classes for this product from those who are less important to satisfy.>
1.9
Operating Environment
The user interface of our recommendation system has already been created and used in larger music streaming and downloading system. Therefore, we won't implement any user interfaces but our recommendation system can be modified in larger system and related interfaces. We only implement a simple user interface for showing system recommendations.
11

This user interface gives chance to display recommendations before integration of webservice and existing music streaming and downloading web application. In main system, user logins first and starts playing and downloading tracks which are created our recommender web service's data. Therefore, Output of our recommendation system is shown in integrated main web application's interface.
1.10
Design and Implementation Constraints
Recommendation systems suffer from three major problems; cold start, huge data and sparsity. Cold start is a potential problem in computer-based information systems which involve a degree of automated data modeling. Specifically, it concerns the issue that the system cannot draw any inferences for users or items about which it has not yet gathered sufficient information.
There are basically two types of this problem. The first one occurs when a new user starts using the system. The system knows little about their preferences and it is necessary to pick some training points for rating so that the system begins learning what the user wants [4]. The second type occurs when a new product is introduced to the system. Again it is essential to rate this item in order to quickly improve the prediction accuracy about it [4].
The next problem is huge data. In many of the environments that these systems make recommendations in, there are millions of users and products. It is quite a challenge to produce high quality recommendations and perform many recommendations per second for millions of customers and items. Thus, a large amount of computation power is often necessary to calculate recommendations. Moreover, at the beginning of the project, we are going to study on our local computers. We are not going to manage with huge data because we have limited memory. After we start using server, we are going to practice with big data.
The third problem is sparsity. Users that are very active contribute to the rating for a few number of items available in the database and even very popular items are rated by only a few number of users available in the database. Because of sparsity, it is possible that the similarity between two users cannot be defined, rendering collaborative filtering useless. The rating matrix
R, which is mentioned in the previous section, might be full of missing entries since many users vote for just a few of the items
1.11
User Documentation
<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.>
1.12
Assumptions and Dependencies
Our end product is planned to be a REST-compliant Web service. There must be Internet connection.
12

2.
2.1
User Interfaces
Music streaming and downloading web application have a user-friendly GUI to provide ease of use and effectiveness to the users with different roles. Besides, our web service is added to web application. Therefore, we are not going to make new user interfaces for the application. Our web service will be integrated to web application and the recommendation result will be displayed through web application GUI. The only interface which we will imple ment is web service interface to display recommendation for companies using this web service.
In Web Service Interface, there are four pages Home, Add Data, Get Started and Contact
13

(Figure 2). This page (Get Started) contains a text field and a button. The user of the system who want to get recommendation fill the text field with proper user id. After s/he fill the text field and click the submit button, new page (Figure 3) is opened and recommendations are shown in this page. It contains a table with three columns which are Song Name, Performer Name and Album
Name. Recommendations are listed in the table according to their song, performer and album names. The row number of the table can change according to how many recommendations are given to the user.
2.2
Hardware Interfaces
The recommendation system can work on any internet connected device. These devices should have some limit requirements to make the application run effectively. We expect that the processor speed and internet speed are high.
2.3
Software Interfaces
First of all the system will work on any platform. Internet connection is a must to reach the system. Moreover, most of the application will be coded by Java. Java APIs of database management tools such as Neoclipse, which is a standalone workbench application to interact with Neo4j. Moreover, some query languages like Cypher will be used. Some tools and software are listed below.
14

2.4
Communications Interfaces
This system is a web application; therefore network connection with TCP/IP protocol is necessary.
3.
This section encapsulates the major software functions and data flow among the participants of the system. The participants include the user and the interagent. The user, in other words the end- user, is the person that makes use of music streaming and downloading web application. The interagent is the R&D team of ARGEDOR and this actor provides the necessary tools to maintain the connection between the user and our system. The overall use case diagram is illustrated in Figure 5.
3.1
Generate Data
User can listen or download track from music streaming and downloading web application.
Track information is collected according to album information, artist information time of action, user information, rating value and channel. This information will fill the database.
15

3.2
Get Recommendation
System can suggest track(s) as a recommendation to user based on the dataset which is refined by users' collaborative approach. The main function of our system shows these tracks based on recommendation algorithms. When a user chooses recommendation part in application, he/she will get the most important point of the project recommendation and project gives user a chance to choose track through recommended tracks according to his/her own previous choices
(Figure 7).
3.3
Provide Dataset
Interagent provides dataset, in other words the big data, in cooperation with music streaming and downloading application
16

3.4
Update Dataset
Music streaming and downloading web application collects 1 million data every day.
Interagent also delivers this 1 million data to our web service. These updates are necessary for making more accurate recommendations
3.5
Intregate Web Service
After the recommendation system project is completed, inter agent integrate this web
17

service to music streaming and downloading web application. Then, users will access to our web service and receive recommendations through the web application
4. Other Nonfunctional Requirements
4.1
Performance Requirements Performance of making recommendation and updating this recommendation is very important issue because we are aiming to make the system realtimed. In other words, the system should have enough speed that users of the system cannot realize the processing of data. In order to make system real-timed, at the end of listening track or after purchasing track system shall update recommendations. Besides, our web service should handle multiple users at the same time.
4.2
Safety Requirements
Database has to be reached securely and its data should not be broken. It also should not change except interagent updates. Moreover, since our dataset contain some personal information of user such as userid, tracks he/she listened, security design is important in the web service.
4.3
Security Requirements
No safety requirements have been identified
5 Other Requirements
The project will be released under GNU General Public License, which allows the use, change and redistribution of the software freely. The philosophy of this license is applied to this recommendation system to achieve the greatest possible use and development by public.
User: This class represents the user entity and it keeps a unique id. Song: This class represents the song entity and it has the fields defined in the previous section. It has an aggregation association with Album and
Performer classes. It contains 22 AlbumInfo and PerformerInfo fields. An Album instance or a Performer instance can be mapped to one or more Song instances. Album: This class represents the album entity and it has the fields defined in the previous section. Performer: This class represents the performer entity and it has the fields defined in the previous section. Listen: This class is a group of instances that represent listening action. Each time a new log is processed, an instance of this class is created. Its fields are defined in the previous section. This class has composition association with User and Song classes. It contains user and song fields. Network: This class encapsulates database related methods and it keep a
GraphDatabaseService object which is the Neo4j database object. It has some specific methods such as createDatabase, registerShutdownHook,clearDb, createNode, createRelationship methods to construct/remove a database and add/delete nodes. The similarity construction requires the traversal of the graph database which is done via depthFirst, breadthFirst and shortestPath methods. The similar user and recommended songs are determined via findNeighbor method. Recommendation: This class represents the recommendation object to be returned to the external system. It contains either a cluster of users that are found similar or a cluster of songs. The user to which this recommendation will be given is kept inside target field. This class has a composition association with the Song class and contains recommendedSong field. It also has an aggregation associatiowith RecommendationList class. Whenever an instance of
18

RecommendationList is deleted, the corresponding instances of Recommendation class still exist.
RecommendationList: This class represents the group of recommendations given to a specific user. It has a unique id. This class has a composition association with User class.
19