finalll

advertisement
Medi-Caps Institute of Science & Technology, Indore
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
Medi-Caps Institute of Science & Technology, Indore
Software Requirements Specification
for
RECOMMANDATION SYSTEM
Submitted To :
Name: Dinesh Bhayal
Designation: Project Guide
Submitted By :
Name:Adiba Khan(0876IT151002)
Name:Gurleen KaurJudge(0876IT151018)
Department of Information Technology
November, 2018
2
Medi-Caps Institute of Science & Technology, Indore
Software Requirements Specification
for
RECOMMENDATION SYSTEM
Internal Examiner
Name: Dinesh Bhayal
Designation : Project Guide
External Examiner
Department of Information Technology
November, 2018
3
4
Table of Contents
Table of Contents .......................................................................................................................... ii
List of Figures .............................................................................................................................. iii
List of Tables …………………………………………………………………………………….iv
1. Introduction.............................................................................................................................. 1
1.1
1.2
1.3
1.4
1.5
Purpose ......................................................................................................................................... 1
Document Conventions ..................................................................................................................
Intended Audience and Reading Suggestions .................................................................................
Product Scope .................................................................................................................................
References ......................................................................................................................................
2. Overall Description ....................................................................................................................
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Product Perspective ........................................................................................................................
Product Functions ...........................................................................................................................
User Classes and Characteristics ....................................................................................................
Operating Environment ..................................................................................................................
Design and Implementation Constraints .........................................................................................
User Documentation .......................................................................................................................
Assumptions and Dependencies .....................................................................................................
3. External Interface Requirements .............................................................................................
3.1
3.2
3.3
3.4
User Interfaces ................................................................................................................................
Hardware Interfaces ........................................................................................................................
Software Interfaces .........................................................................................................................
Communications Interfaces ............................................................................................................
4. System Features .........................................................................................................................
4.1
4.2
System Feature 1 ............................................................................................................................
System Feature 2 (and so on)..........................................................................................................
5. Other Nonfunctional Requirements .........................................................................................
5.1
5.2
5.3
5.4
5.5
Performance Requirements .............................................................................................................
Safety Requirements .......................................................................................................................
Security Requirements ....................................................................................................................
Software Quality Attributes ............................................................................................................
Business Rules ................................................................................................................................
6. Other Requirements ..................................................................................................................
Appendix A: Glossary .....................................................................................................................
Appendix B: Analysis Models .........................................................................................................
Appendix C: To Be Determined List .............................................................................................
5
LIST OF FIGURES
Figure No.
Figure Name
Page No.
1
ER- Diagram
2
6
LIST OF TABLES
Table No.
Table Name
Page No.
1
Data Dictionary
2
7
1. Introduction
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
API
Application Programming Interface
Big Data
A collection of data sets so large and complex
that it becomes difficult to process using onhand database management tools or traditional
data processing applications
Cold Start
The issue that the system cannot draw any
inferences for users or items about which it not yet
gathered sufficient information
IEEE
The Institute of Electrical and Electronical
Engineers
OS
Operating system
8
RMSE
Root Mean Square Error
UML
Unified Model Language
Web Service
A software function provided at a network
address over the web or the cloud
UI
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. External Interface Requirements
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
implement 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. System Features
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 enduser, 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
Download
Related flashcards
Create Flashcards