Uploaded by rje75

SRS Use-Cases

advertisement
Contents
1.
2.
3.
Introduction
1.1.
Purpose
1.2.
Scope
1.3.
Definitions, Acronyms, and Abbreviations
1.4.
References
1.5.
Overview
Overall description
2.1.
Product perspective
2.2.
Product functions
2.3.
User characteristics
2.4.
General constraints
2.5.
Assumptions and dependencies
Specific Requirements
3.1.
3.2.
External interface requirements
3.1.1.
User interfaces
3.1.2.
Hardware interfaces
3.1.3.
Software interfaces
3.1.4.
Communication interfaces
Functional requirements
3.2.1.
Authentication Module
3.2.2.
Create NFT Module
3.2.3.
Library Page Module
3.2.4.
Auction System Module
3.2.5.
Song Info Page Module
3.3.
Performance requirements
3.4.
Design constraints
3.5.
Attributes
3.6.
Data Flow Diagrams
1
Software Requirements
Specification
1. INTRODUCTION
1.1 Purpose
The purpose of this section is to present a detailed description of the
platform Musomatic. It will explain the purpose and features of the system, the
interfaces of the system, what the system will do, the constraints under which it
must operate and how the system will react to external stimuli. This document is
intended for both the stakeholders and the developers of the system.
1.2 Scope
The music industry is in a state of flux. The demise of the CD and digital
downloads in favor of online music streaming has significantly strangled profits particularly for the artists themselves.
Artists are struggling to make sense of the mess that is royalty distribution
in its present form and find it difficult to keep the fair share of the revenue they
generate on existing platforms.
With or without the buzz, one of the most powerful and overlooked impacts
of NFTs is on the music industry. NFTs have the power to change the game for
independent artists by providing a new way to earn an income (while connecting
with fans), and this kind of change has been long overdue.
2
1.3 Definitions, Acronyms, and Abbreviations
1.3.1 Abbreviations
API - Application Programming Interface
UI - User Interface
DFD - Data Flow Diagram
NFTs - Non-Fungible Tokens
DeX - Decentralized Exchanges
IPFS - InterPlanetary File System
JSON - JavaScript Object Notation
RPC Node - Remote Procedure Call Node
1.3.2 Definitions
Blockchain : A blockchain is a distributed database that is shared among the
nodes of a computer network. As a database, a blockchain stores information
electronically in digital format. Blockchains store data in blocks that are then
linked together via cryptography. The goal of blockchain is to allow digital
information to be recorded and distributed, but not edited.
Cryptocurrency : A cryptocurrency, crypto-currency, or crypto is a digital
currency designed to work as a medium of exchange through a computer network
that is not reliant on any central authority, such as a government or bank, to
uphold or maintain it. The advantages of cryptocurrencies include cheaper and
faster money transfers and decentralized systems that do not collapse at a single
point of failure.
3
NFTs : A non-fungible token (NFT) is a non-interchangeable unit of data stored on
a blockchain, a form of digital ledger, that can be sold and traded. Types of NFT
data units may be associated with digital files such as photos, videos, and audio.
Because each token is uniquely identifiable, NFTs differ from blockchain
cryptocurrencies, such as Bitcoin.
Smart Contracts : A smart contract is a self-executing contract with the terms of
the agreement between buyer and seller being directly written into lines of code.
The code and the agreements contained therein exist across a distributed,
decentralized blockchain network. The code controls the execution, and
transactions are trackable and irreversible.
Smart contracts permit trusted transactions and agreements to be carried out
among disparate, anonymous parties without the need for a central authority,
legal system, or external enforcement mechanism.
Ethereum : Ethereum is a decentralized, open-source blockchain with smart
contract functionality. Ether is the native cryptocurrency of the platform. Among
cryptocurrencies, Ether is second only to Bitcoin in market capitalization.
Ethereum was conceived in 2013 by programmer Vitalik Buterin.
Polygon : Polygon, formerly known as Matic Network, is a blockchain scalability
platform and framework for connecting and building blockchain networks
compatible with Ethereum. The network also refers to itself as “Ethereum’s
internet of blockchains” because one of Polygon’s main missions is aggregating
scalable solutions to support a multichain Ethereum ecosystem.
Metamask : MetaMask is a software cryptocurrency wallet used to interact with
the Ethereum blockchain. It allows users to access their Ethereum wallet through
a browser extension or mobile app, which can then be used to interact with
decentralized applications.
4
MATIC : MATIC is the native cryptocurrency of the Polygon network and is used
to help drive development across the network and can be used for staking and
paying for transaction fees. Users can earn MATIC tokens by providing
computational resources and services to the Polygon network.
IPFS : IPFS(InterPlanetary File System) is a file sharing system that can be
leveraged to more efficiently store and share large files. It relies on cryptographic
hashes that can easily be stored on a blockchain. Nonetheless, IPFS does not
permit users to share files with selected parties.
1.4 References
1. Pressman, R. S., & Maxim, B. R. (2015). Software Engineering: A
Practitioner’s Approach. 8th edition. McGraw-Hill.
2. Aggarwal, K. K., & Singh, Y. (2007). Software Engineering. 3rd edition.
New Age International Publishers.
3. https://consensys.net/blog/
4. https://ethereum.org/en/developers/docs/
5. https://www.ibm.com/in-en/topics/what-is-blockchain
6. https://en.wikipedia.org/wiki/Main_Page
7. https://academy.binance.com/en
8. https://opensea.io/
9. https://rarible.com/
5
1.5 Overview of the document
The rest of the document deals with all the main features of this application.
It not only describes various functions but also gives details about how these
functions are related to each other. Apart from the data flow diagrams, the
document also contains cost estimates for developing this application. Various
risks associated with the system have also been mentioned along with the ways to
mitigate them.
The next chapter, the Overall Description section, of this document gives an
overview of the functionality of the product. It describes the informal
requirements and is used to establish a context for the technical requirements
specification in the next chapter.
The third chapter, Requirements Specification section, of this document is written
primarily for the developers and describes in technical terms the details of the
functionality of the product.
Both sections of the document describe the same software product in its entirety,
but are intended for different audiences and thus use different language.
6
2. THE OVERALL DESCRIPTION
2.1 Product Perspective
Musomatic is a product that requires some additional hardware and
software interfaces to function which includes the OS, a web browser, a
cryptocurrency wallet (Metamask), and a stable internet connection. When
released, the final product would be the first version of the application. It will be
designed as a user centered product, which could be accessed to give a
personalized experience to any authenticated user.
2.2 Product Functions
The application will be capable of performing the following functions.
The functions depend on the user’s level and permission package, as
explained in the user characteristics.
● Provide Authentication for both General User and Artist through SignUp
Page, Login Page and Metamask wallet login
● Provide each user with an account and an Artist with an account and
verified checkmark on his profile
● Users can see and change their personal information after visiting their
dashboard.
● Auction system where User/Artist can bid for their favorite NFTs
● Library where users can see the Trending NFTs, Recently Added NFTs, with
various functionalities like searching, sorting, filters on Genres, Lyrics,
Instrument used etc. for quickly accessing the NFTs
● Song Info Page where users can get detailed information about a specific
NFT
7
● Song Info Page also contains an Audio Player for listening to the demo of
the song and a Chat feature where the current owner of the NFT can chat
with the creator for that particular NFT
● Artist Analytics Page where an Artist can check the detailed information
regarding his/her NFTs and the Transaction details
● Users/Artists can buy NFTs through the Auction or can directly visit the
NFT (SongInfo Page) and buy the NFT via connecting with Metamask
● FAQ page for the users to clarify certain doubts about the website
● Users can contact the admin of the application for any particular queries
through Contact Us Page
2.3 User Characteristics
The intended users of this application will be people who are inclined
towards finance, music and the blockchain sector. Other people who perform
cryptocurrency/NFT trading on a regular basis can also benefit from the
application.
The users are expected to be Internet literate and be able to understand the
concept of NFTs and how the Metamask and Auction system works. They should
be able to trade their cryptocurrency in exchange for the NFT.
2.4 General Constraints
● The application will only be available in english.
● Loading time of the marketplace can be a little high because it takes some
time to read data from the blockchain. In order to solve this, a caching
system like Redis can be implemented during future iterations.
8
2.5 Assumptions and Dependencies
● A web browser is required to access the website.
● Basic knowledge of cryptocurrencies and blockchain.
● Users must be connected to the Internet.
● Users must know how to operate Metamask.
● There are some dependencies on 3rd party softwares like Metamask, IPFS
and Font Awesome.
9
3. SPECIFIC REQUIREMENTS
3.1 External interface Requirements
There are a few external interfaces being used in this project➔ Data being stored on the Ethereum blockchain (Polygon Networklayer 2 solution).
➔ Usage of a third-party cryptocurrency gateway & wallet (Metamask).
➔ Hosting the Website frontend on GitHub Pages.
3.1.1 User Interfaces
● The product website will be made very simplistic and responsive,
thus having an UI which is easy to access. It will be able to run on any
device with a modern web browser but mainly optimized for desktop
users.
● Though the UI will be developed to look a little bit different on
desktop and mobile devices, most of the functionalities will be
available to both types of users.
● Content on extra-large screens will be displayed the same as on
desktop as a max-width of 1500px will be set for the website
contents.
● Required web pages include-
○ Static Pages: To portray the functioning of the platform
○ Marketplace/Library: Page to display all NFTs
10
○ Individual NFT page: Separate page that displays data and
characteristics associated with the particular NFTs.
○ User/Artist dashboard: User dashboard to display NFTs
owned by the user and his/her details.
○ Create NFT page: A page displaying a form so the
musicians/artists can create NFTs.
○ Auction Page: A page to place bids by the bidder on his/her
favorite NFTs.
○ Contact Us Page: A page to send queries to the admin of the
website.
○ FAQ and Terms and Condition Page: A Page listing the
frequently asked questions and Terms and Conditions of the
application.
3.1.2 Hardware Interfaces
●
RAM: 2GB
● Storage: 8GB
● Processor: i3 or above
3.1.2.1 Frontend
There is no specified screen resolution for accessing the
website. The website can be used on any screen size.
11
3.1.2.2 Backend
The smart contracts will act as the backend for the application.
Logic will be written in the Solidity programming language and
deployed on the blockchain.
3.1.3 Software Interfaces
The application will be implemented in React and Solidity. VS Code
will be used as a text editor. The Truffle Framework will be used to test,
compile and deploy smart contracts. Ganache will be used for simulating a
local blockchain for development purposes. Git will be used for version
control and Github will be used for hosting the repository.
The softwares required in the development of the application include● Truffle framework
● React JS for frontend
● VS Code as a text editor
● Git and GitHub for version control
● Ganache as a simulated blockchain environment
● HTML
● CSS
● JavaScript to write tests
● Solidity to write smart contracts
● Adobe Suite(XD, Photoshop) for Designing
12
3.1.4 Communication Interfaces
The system requires HTTPS to communicate with the database. The
system and database can be configured to be accessed via any available
port. The web based UI is the only means of communication between the
user and the system, though the user can directly send an email to the
admin in case of any queries through Contact Us Page. The system is
accessible through all popular modern web browsers that interact with
HTML pages and access metamask.
3.2 Functional Requirements
3.2.1 Authentication Module:
● The Authentication involves 2 steps:
➔ Sign Up for new users
➔ Login for existing users
● In order to Sign up, the user/artist needs to fill the registration
form with the required information.
● If registering as seller, then a seller ID is created
● Email verification is carried out to verify the user/artist.
● Users/Artists get connected to their Metamask wallet
automatically after successful login in.
● All the information of the User/Artist is stored in a User
database.
● Spectator needs to perform the Metamask login to make the
browser web3 enabled, but a Buyer has to login by entering the
registered email-ID and password.
13
● If successful, User/Artist can access the application, otherwise
he/she will be redirected to the login page with the error
message.
3.2.2 Create NFT Module:
● The verified Artist can create an NFT of its Song by visiting the
Create Page on the application.
● The artist needs to fill in the required fields for creation of the
NFT and upload the Music file for which he will also pay a gas
fee for storing the NFT on the Blockchain (i.e. Polygon
Network)
● The following data will be stored and associated with the NFT
on the blockchain whenever a new NFT is created.
14
3.2.3 Library Page Module:
● Users/Artist will be able to see the Trending NFTs and the
Recently added NFTs on the Library Page.
● Various functionalities like Searching, Sorting are provided for
quick access to the NFTs.
● Various filters options are also available like Genre, Lyrics,
Instrument used are also available on the Library Page.
● Users/Artists can visit the Song detail Page by clicking on a
specific NFT for more details.
3.2.4 Auction System Module:
● Buyer can place a bid for an NFT by visiting the Auction Page
on the application.
● The bid is validated through an Auction database and stored in
it with the specified details of the NFT and the user.
● After the bidding process is over, the max bid is chosen from
the database.
● The user details of the winning bid are processed and a
winning message is displayed to the Bidder and the NFT
seller/owner.
● Transaction request is generated for buyer, payment is
processed and communicated through blockchain
● After payment is processed, the ownership of NFT is
transferred to the seller.
● In case, an NFT is sold again, a part of the transaction is
transferred to the seller as royalty.
15
3.2.5 Song Info Page Module:
● Page displays detailed information regarding the NFT and creator
details.
● Links to other platforms where the song is uploaded is also
available like Spotify, Amazon Music, YouTube Music etc.
● Audio Player is also available on the page with a 30 sec song
for the demo purpose.
● Sale History modal is also available to see the past owners and
creator of the NFT.
● To directly Buy the NFT instead of the Auction system, BUY
option is available on the page to buy the respective NFT
through Metamask connect.
3.3 Performance Requirements
● System should respond and generate output within 10 seconds when
the user interacts with the system and Blockchain, else a message
defining the error should be shown.
● Metamask is required for connecting to the Blockchain via web
browser.
● After successful connection to Blockchain, NFTs should be displayed
within 5-10 seconds as loading data from Blockchain is slow.
3.4 Design Constraints
● A max-width of 1500px would be applied to the website contents. So,
users on extra large screens will have to zoom in to view the website
properly.
● For normal screen users, the website contents are perfectly visible
but some components are missing in the mobile view.
16
3.5 Attributes
3.5.1 Reliability
The application should deliver appropriate and correct NFT data to
the users. Any false information displayed would result in dissatisfaction
from the users.
Song Info Page should be updated with the latest price of the NFT.
Auction Page should be display the correct and latest information to the
Buyers regarding bids on the respective NFT.
3.5.2 Security
The server on which the application resides will have its own security
to prevent unauthorized write/delete access. There is no restriction on read
access. The system on which the user uses the application will have its own
security.
There is no special protection built into this system other than that the
information of the users shall be encrypted before transferred to the
database in order to maintain the security of the crucial information about
users.
3.5.3 Maintainability
Maintainability of the application would be a little hard sometimes as
there are several dependencies like IPFS, Metamask etc and the tools being
used are continuously being updated by developers. So, frequent checks
would have to be made to ensure proper and desired functioning of the
application.
17
Use Cases
1. SIGN UP
1.1 Brief description
This use case describes how the actors can Sign up in Musomatic.
1.2 Actor
The User and the Artist are the actors in this use case.
1.3 Pre-condition
The actor should be present on the sign up page.
1.4 Flow of events
1.4.1 Basic flow
● The system will prompt the user to enter the Name, Email id, and
Password or connect through Metamask.
● The actor will enter the above details asked by the system.
● A verification email will be sent to the provided Email id.
● The user will click on the verification link which is enclosed in the
received email.
● The system will store the data into the user database.
1.4.2 Exception flow
18
● If in the basic flow, the actor enters an email that was already present in
the database, an error stating the same should be displayed.
● If the actor does not click on the verification email within 30 minutes,
the link will be disabled and the whole sign up process would have to be
started from scratch.
1.5 Post-condition
A message stating the successful creation of an account should be displayed
and the actor should be redirected to the Sign In page.
2. SIGN IN/METAMASK CONNECT
2.1 Brief description
This use case describes how the actor can Sign In into Musomatic.
2.2 Actor
The User and the Artist are the actors in this use case.
2.3 Pre-condition
The actor should be present on the sign in page.
19
2.4 Flow of events
2.4.1 Basic flow
● The system will prompt the user to enter the Email id, and Password
or connect through Metamask option.
● The actor will enter the above details asked by the system.
● Provided credentials would be checked in the database in case of email
sign in, and if present the actor should be signed in successfully.
● For connection through Metamask, user details are checked by
Metamask servers and if present the actor should be signed in
successfully.
2.4.2 Exception flow
● If in the basic flow, the actor enters an email or password that is not
present in the user database or the user detail is not there on Metamask
servers, then an error stating the same should be displayed and the
actor must not be signed in.
2.5 Post-condition
The actor should be redirected to the dashboard.
3. LIBRARY PAGE
3.1 Brief description
This use case allows the actor to search for any NFTs. Users can also see the
Trending and Recently Added NFTs on the Marketplace, various filters based
20
on Genre, Instrument Used, searching NFT is also provided.
3.2 Actor
The User and the Artist are the actors in this use case.
3.3 Pre-condition
The actor should be signed in and connected to the respective Blockchain.
3.4 Flow of events
3.4.1 Basic flow
● The actor can perform the search through the search menu available on
the page.
● Any of the categories in which the search is to be performed can be
chosen from the options.
● Entered characters will then be looked into the fetched list of NFTs for
the chosen category and a live response giving the search results will be
shown.
● The actor will then click on any of the returned results and be
redirected to the particular page.
● The actor can visit the Song Info/NFT details page by clicking on a
particular NFT.
3.4.2 Exception flow
● If the entered characters do not match to any items in the fetched list of
NFTs from the Blockchain, then a message stating “No results found!”
should be displayed.
3.5 Post-condition
21
The actor should be redirected to the particular NFT detail Page for which he/she is
looking for.
4. USER/ARTIST DASHBOARD
4.1 Brief description
This use case describes the user dashboard on which the bought NFTs and
detailed information can be viewed.
4.2 Actor
The User and the Artist are the actors in this use case.
4.3 Pre-condition
The actor should be signed in.
4.4 Flow of events
4.4.1 Basic flow
● The actor can view his/her owned NFTs on the dashboard page.
● Bookmarked items by the actor will also be displayed.
● Top 4 most popular NFTs bought by the user will be displayed below
the bookmarked items.
4.4.2 Alternative flow
● If the actor is new to the website, then a detailed description of what
the dashboard page will show will be displayed to the actor.
4.5 Post-condition
22
The actor can open charts and tables and look at the analyzed data.
5. CREATE NFT
5.1 Brief description
This use case describes the Create Page on which the Artist can create NFTs
and update the Blockchain database.
5.2 Actor
The Artist is the actor in this use case.
5.3 Pre-condition
The actor should have signed up and completed the KYC process.
5.4 Flow of events
5.4.1 Basic flow
● The Artist will be asked to fill a form specifying detailed information
regarding the NFT..
23
● After that, the user needs to agree to terms and conditions and click the
Submit button.
● Pay the gas fee for creating the NFT and store it on the blockchain.
5.4.2 Exception flow
● If any problem occurs during NFT creation then an error message
stating the same will be displayed, and the required changes need to be
done.
5.5 Post-condition
The users and artist must then be able to access the new data through
the application
6. SONG INFO PAGE/NFT DASHBOARD
6.1 Brief description
When the actor will search a NFT, it will take the actor to the specific
Song/NFT dashboard. This dashboard displays all the information like Creator,
Genre, Instruments used, Lyrics etc. Audio Player will be there with a demo
song for 30 seconds. Sale History about the holdings of the NFT will be
displayed.
6.2 Actor
The User and the Artist are the actors in this use case.
6.3 Pre-condition
The actor should be signed in.
24
6.4 Flow of events
6.4.1 Basic flow
● The actor can view the Song dashboard after searching for the
particular NFT name.
● The Song/NFT dashboard will then be displayed for the particular song/NFT.
● NFT/Song name, description, and associated details like creator, Lyrics,
Genre, etc will be displayed.
● Audio Player will be available with 30sec demo song.
● Buy Button is available for the user to buy the NFT
● The Sale History modal displays the previous owners of that NFT to the user.
6.4.2 Alternative flow
● The actor can also view the NFT/Song dashboard by clicking on a the
bookmarked items on the user dashboard.
6.5 Post-condition
The actor should be able to Buy the NFT and can listen the demo song.
7. AUCTION SYSTEM
7.1 Brief description
When the actor will search for the Auction Page, he/she will be redirected to
the Auction dashboard where the NFTs are listed and the user can bid for their
favorite NFTs.
25
7.2 Actor
The User and the Artist are the actors in this use case.
7.3 Pre-condition
The actors should be signed in.
7.4 Flow of events
7.4.1 Basic flow
● The actor can view the NFT dashboard after searching for the particular
NFT name or Artist name.
● The NFT/Song Info Page will then be displayed for the particular NFT.
● Song’s name, description, and associated details like Creator,
description, instrument used, Genres, lyrics etc. will be displayed.
● A quick summary table with metrics like highest bid, no. if bids, average
bids etc. will also be shown.
● Options to place the bids will be available for the user.
7.4.2 Alternative flow
● The actor can also view the NFT/Song dashboard by clicking on the
bookmarked items on the user dashboard.
7.5 Post-condition
The actor should be able place the bids on stand for the NFTs.
26
8. FAQ
8.1 Brief description
The FAQ functionality in the application is meant to resolve basic doubts of
the users about the website.
8.2 Actor
The User/Artist and the admin are the actors in this use case.
8.3 Pre-condition
The actor should be on the faq page.
8.4 Flow of events
8.4.1 Basic flow
● The users view answers to some basic questions on the faq page.
● The admin will put up answers to general questions about the website
in this section.
8.5 Post-condition
The actor should be able to ask questions to the admin in case the answer is
not available on the faq page.
27
9. CONTACT US
9.1 Brief description
Contact/Help function allows users to send an email to the admin in case of
any queries/suggestions for the website.
9.2 Actor
The User/Artist and the admin are the actors in this use case.
9.3 Pre-condition
The actor should be on the contact us page and a message should be written.
9.4 Flow of events
9.4.1 Basic flow
● The users can ask questions to the admin about anything on the website.
● The admin can reply to the queries on the provided email id.
9.4.2 Exception flow
● If an email id is not provided by the user, then the admin cannot reply to
the query.
9.5 Post-condition
If the admin feels that the question is really sensible, then it can be added to
the FAQ page.
28
10. 404 PAGE
10.1 Brief description
If an actor tries to access any page which is not defined for the application,
then it will redirect to a 404 page.
10.2 Actor
The User and the Artist are the actors in this use case.
10.3 Pre-condition
The actor should be trying to search for a page on the application.
10.4 Flow of events
10.4.1 Basic flow
● The actor will try to search for a page on the application.
● If the page does not exist, then the application will redirect the actor to a
404 page stating “Page Not Found!”.
10.5 Post-condition
A button linking to the homepage can be pressed by the actor to return to the
homepage.
29
Use Case Diagram
30
Risk Management
31
Download