Specification history

Transcription

1 Specification history Version Date Author Change comment Kristel-Maria Kadajane, Liina Land, Liis Ojokas Kristel-Maria Kadajane, Liina Land, Liis Ojokas Kristel-Maria Kadajane, Liina Land, Liis Ojokas Kristel-Maria Kadajane, Liina Land, Liis Ojokas Kristel-Maria Kadajane, Liina Land, Liis Ojokas Kristel-Maria Kadajane, Liina Land, Liis Ojokas Kristel-Maria Kadajane, Liina Land, Liis Ojokas Initial version Defined, system, goals, dependencies, scenarios, i* diagrams Expectations, previous software systems analysis, analysis of Hard data, mock-ups, first version of requirements Diagrams: KAOS, class diagram, use case diagrams, state diagram, scenario diagram Total redesign according to specification template; two separate s for requirements and as is analysis s revised; system requirements added; traceability fixed s revised; requirements prioritization; value and cost calculations 2

2 Table of Contents 1. Introduction Purpose Scope Definitions and Acronyms References Overall description Product perspective Product functions User characteristics Constraints Expectations Specific requirements External interface requirements Mock-ups System requirements Data requirements Functional software requirements Non-functional software requirements Hardware requirements s hierarchy Appendices Diagrams Analytic Hierarchy Process

3 1. Introduction 1.1. Purpose The purpose of this paper is to present a description of requirements for digitized coin collection management system. In the following are described the system s specific features, constraints and development scope Scope The coin collecting system is specifically designed for a collector for managing their collection and simplifying coin trading. Our proposed solution will require software development for a mobile platform. Primary scope - we propose using Android and ios platform as they are in a global context the most used mobile platforms. In overall, the primary scope includes: 1) digital coin collection management 2) Virtual Marketplace. Secondary scope - we propose developing a news feed for information of where and when Central banks plan new releases of coins. Including an alerts system - user may subscribe to alerts for specific kinds of releases Definitions and Acronyms Term Collector Seller Trader Buyer Collection Album Page Slot Coin grading Stakeholder User CCSS Definition Someone who collects coins Someone who sells coins Someone who trades coins Someone who buys coins Coin collection which is managed by the collector A folder to hold removable pages that are used to insert coins into for storage and viewing purposes A subdivision of the album that has a predefined number of slots where the coin collector can insert coins A space on a page in an album that holds exactly one coin The process of determining the grade or condition of a coin Any person with an interest in the project Someone who interacts with the mobile phone - mostly coin collector in its different roles Coin Collecting Software System for digitized coin collection management. Product to be developed. Collaborative coin A database which is used by the mobile to store all entered unique coins. Each 4

4 database Virtual marketplace System Collaborative database Digitized coin collection management system Cloud storage Transaction unique coin entered by the mobile user will be added to the database so that other users could also use the entered data. Marketplace where coins are traded using the mobile Includes both mobile and environmental factors such as PayPal, that play a role in coin community. Each user, that has inserted coins to the mobile, contributes automatically in creating a collaborative database, that consists all coins that are inserted to the database. When user deletes coins, the data remains to the collaborative database. Coin management system based on mobile app, that is going to be developed in primary scope. enables digitized management, e.g coin management via mobile. All the data, that is received from users (coin data, user s personal information data etc) is stored in Amazon cloud, which is external partner of mobile via API integration. A digital instance of buying, selling or trading something in mobile. Third-party authentication Cached images New users have to verify themselves via third-party app - PayPal during 7-days period after creating an account in the mobile environment. For optimizing and increasing loading time when using the, it uses the cached images. Scanning Table 1 - Definitions and acronyms A mobile functionality that uses mobile back-side camera for taking picture of the coin for coin database References The following is based on IEEE Recommended Practice for Software s Specifications (200). Descriptions of the current can be found from a separate process. 5

5 2. Overall description This section will give an overview of the whole system. The goal is to explain what is the basic functionality of the mobile. The overview is given only for the primary scope of the project Product perspective The product is a new mobile which has two major functionalities (which will be explained more thoroughly below): coin collection management and virtual marketplace. The coin collection management uses a collaborative database where all the coins are stored. This means that when new coins are added to system - they re also stored in the collaborative coins database - this helps other users to identify other unknown coins. The mobile also has a separate database in the cloud where all coin collections and transactions in the virtual marketplace are stored. This means that the mobile syncs data into the cloud. This will help to not overload the users phone storage when using the mobile. The main users of the coin collection management functionality are different roles of coin collectors: collection builder, trader, seller, buyer, who all want to manage their coin collection. Virtual marketplace is used by roles whose goal is to have different transactions with the coins: trader, seller, buyer. Also the Virtual Marketplace is integrated with Paypal through Paypal API - this means that different transactions which require money transactions can be done with Paypal. All the users need to log in to the for using the offered functionality. For login also PayPal authentication can be used. Diagram 1 - System environment 2.2. Product functions This section outlines all the product functions in use cases. The collector represents the user of the mobile in all different collector s roles. 6

6 Collection management - create collection Diagram 2 - Create collection use case Brief description Collector (user of the mobile ) creates a new coin collection where coins can be added. Step-by-step description Before this use case can be initiated, the collector has to be signed in to the mobile. 1. The collector chooses button Create new collection 2. New form is opened with settings for the new collection such as name of the collection. 3. Collector names the new collection and presses button Add 4. The system saves a new collection with specified name and the collector as the owner in the Cloud database Collection management - add new coin to collection Diagram 3 - Add coin to collection use case Brief description Collector (user of the mobile ) creates a new coin collection where coins can be added. Step-by-step description Before this use case can be initiated, a coin collection has to exist beforehand (coin is added to a specific collection). 1. In coin collection the collector chooses button Add coin 2. A menu opens where collector chooses Add coin manually or Scan coin 3. If collector chooses to manually add coin a new form open where coin data can be entered. 4. Entered data or scanned coin is compared to collaborative coin database - if a match is found collector is notified and coin data prefilled. 5. When form is filled, collector presses Save. 6. If coin didn t previously exist in the collaborative database, it is added there. 7. System generates a slot for the coin in the collection. 8. Data is added to Cloud database. 9. Collector is shown success message with added coin s slot location. References KAOS responsibility model in Appendices 7

7 Collection management - Remove coin from collection Diagram 4- Remove coin from collection use case Brief description Collector (user of the mobile ) removes a coin from the collection. Step-by-step description Before this use case can be initiated, the coin has to exist in the coin collection. 1. The collector chooses a specific coin from the collection. 2. In coin view mode additional option Remove coin is shown. Collector presses button. 3. Collector is asked confirmation Are you sure you want to remove this coin? 4. Collector confirms. 5. System saves all data: coin remains in the collaborative coins database, but is removed from the specific collector s collection Collection management - search collection Diagram 5 - Search coin from collection use case Brief description Collector (user of the mobile ) searches for a specific coin in the collection. Step-by-step description Before this use case can be initiated, there has to exist coin collection with coins. 1. The collector chooses a specific collection from where to look for a coin. 2. Collector presses button Search 3. Search bar opens, collector enters search term and presses enter either from phone s keyboard or button Search. 4. Collection is searched for entered term. 5. Results are displayed Collection management - view coin Diagram 6 - View coin from collection use case 8

8 Brief description Collector (user of the mobile ) views a coin from the collection. Step-by-step description Before this use case can be initiated, there has to exist a coin in the collection. 1. Collector chooses a specific coin from the collection. 2. Chosen coin s detailed view is opened. 3. Additional functionality via buttons Remove, Edit or Send to trade is shown to the collector (if the collector wants to edit coin s data, remove it from the collection or send it to a trade in marketplace) Virtual marketplace - view coins in marketplace Diagram 7 - View coins in the marketplace use case Brief description Collector (user of the mobile ) views a coin from the collection. Step-by-step description Before this use case can be initiated, the collector has to be signed in to the mobile. 1. From the s dashboard collector chooses Marketplace. 2. System queries data of all coins available for trading in the Marketplace. 3. Marketplace is opened and displays all found coins. References Mock-ups: Image 1 - Dashboard; Image 2 - Virtual Marketplace Virtual marketplace - send coin for trading in marketplace Diagram 8 - send coin for trading in marketplace Brief description Collector (user of the mobile ) sends a specific coin from the collection for trading in the marketplace. Step-by-step description Before this use case can be initiated, the coin needs to exist in the collection. 1. Collector chooses a specific coin from the collection. 2. Chosen coin s detailed view is opened. 3. Collector chooses button Send to trade. 4. System sets coin status IN_TRADE and makes it available in marketplace. References Mock-ups: Image 1 - Dashboard; Image 2 - Virtual Marketplace 9

9 2.2.8 Virtual marketplace - choose coin from marketplace Diagram 9 - choose coin for trading in marketplace Brief description Collector (user of the mobile ) chooses a coin from marketplace that they re interested in and would like to buy or exchange. Step-by-step description Before this use case can be initiated, a coin needs to be in trade in the marketplace. 1. Collector opens marketplace. 2. System queries all coins which are in trade but without the second party (no offer made yet). 3. Collector chooses specific coin from marketplace. 4. Collector presses button Make an offer. 5. System sends notification to the other collector who set up the coin in the marketplace. 6. Collector must wait for confirmation. References Mock-ups: Image 1 - Dashboard; Image 2 - Virtual Marketplace; Scenario diagram in appendices Virtual marketplace - payment with Paypal Diagram 10 - payment in marketplace Brief description Collector (user of the mobile ) pays for a coin in the marketplace. Step-by-step description Before this use case can be initiated, the collector must have chosen a specific coin from the marketplace, that they re interested in and the offer must be accepted from the trade initiator (seller of the coin). 1. Collector goes to chosen coins detailed view. 2. Collector presses button Buy with Paypal 10

10 3. Confirmation page with coin s data and price is shown to the collector. 4. Collector presses Confirm. 5. Terms and conditions are shown to the collector. 6. Collector accepts terms of conditions and presses Paypal. 7. System sends via Paypal API information about the payment to Paypal. 8. Next Paypal is opened, collector logs in and confirms payment in Paypal. 9. Confirmation to the system is sent from paypal. 10. Collector is shown success page User characteristics The main user of the mobile is a coin collector. The coin collector s main goal is to manage their coin collection (reference to goal 1.4). The main user - coin collector may have different roles and depending on the role different functionality of the is used. In the collection builder role collection management functionality is used. In the buyer, seller, trader role the virtual marketplace functionality is used. If the user wants to use marketplace functionality, this means that contact information must be provided. We expect the users to be somewhat familiar with mobile s User class diagram Diagram 11 - User class diagram User class diagram represents how there can be two different types of users: collectors and traders. Overall they re both mobile users but they need to provide different data in order to be able to use the functionalities the mobile offers. 11

11 Strategic dependency model Diagram 12 - Strategic dependency model (references in goals to analysis table in ) Strategic rationale model Diagram 13 - Strategic rationale model (references in goals to analysis table in ) 2.4. Constraints The Internet connection is one important constraint for the. Since our goal is to use the mobile phone s own storage as less as possible - all data needs to synced to the cloud (and also queried from the cloud). It is crucial that there is Internet connection for the to function. 12

12 2.5. Expectations Expectations to system and software - what needs to be true for requirements System expectations ID Statement Description Source Support material SE-1 User downloads the app For using designed system the user must have the downloaded to their mobile phone SE-2 Coins are collected Assumption that collector always collects coins SE-3 Coin collection consist of at least one coin Coin collection cannot exist without coins in the collection which means at least one coin should be in the collection Use case Collection management - add new coin to collection; Analysis of Hard data Coins in collection class diagram; logical structure of Data SE-4 Coin collection must exist before adding a coin A coin collection must exist before adding a new coin to the collection Use case Collection management - add new coin to collection State diagram; Class/object diagram SE-5 Marketplace is used for trading Assumption that marketplace is only used for different transactions with coins (buying, selling, trading) Use cases related to Virtual marketplace; Scenarios S- 3, S-4, S-5 Scenario diagram SE-6 Trading with the goal of getting rid of coin Assumption that when coin is set up for a trade, the collector expects to get rid of it Scenarios S- 3, S-4, S-5 Scenario diagram; strategic rationale model SE-7 Coin must exist in collection before removal Assumption that coin cannot be removed from collection when it does not exist in the collection Collection management - Remove coin from collection Class/object diagram SE-8 Collectors participate in trades Assumption that coin collectors at some point will participate in coin trading (in order to get new coins or get rid of old coins) Scenarios S- 3, S-4, S-5 Scenario diagram; Class/object diagram SE-9 Coin trade is between Assumption that coin trade (buying, Scenarios S- Scenario diagram 13

13 two collectors Table 2 - System expectations selling, trading) can only be done between two collectors (not more) 3, S-4, S Software expectations ID Statement Description Source Support material SWE-1 One account per user in the software system Assumption that in the system it is possible to create one user account for one user (no duplicates) Class/object diagram SWE-2 User must be logged in For all actions in the mobile the user must be logged in Use case Virtual marketplace - view coins in marketplace; Collection management - create collection SWE-3 System enables profile management for users. System has profile editor so that user can manage his/hers personal profile (fill the personal detail fields, choose privacy settings) Goals: 5.1, 6.1; Analysis of Hard data - traders data Class/object diagram SWE-4 User profile can be accessed by other users in the system Assumption that user profile is not only for personal use but can be accessed by other users in system (for example during the trade) Analysis of Hard data - traders data SWE-5 Marketplace without any trades Assumption that marketplace may be empty - references that there are no coins up for trade Use case Virtual marketplace - view coins in marketplace; Scenarios S-3, S-4, S-5 Mock-up image 2 SWE-6 Search without results Assumption that not all searches give results Table 3 - Software expectations Use case Collection management - search collection 3. Specific requirements This section describes specifically the s functionality and all its features. Column traceability shows connections between requirements. s priority levels (from lowest to the highest priority): minor, major, critical. 14

14 3.1. External interface requirements ID Statement Description Priority Source Support material Traceability EIR-1 should have PayPal as a thirdparty verification User should be able to verify his/hers account with PayPal. For verification, software system has API integration with Paypal. Major Goal 1.4 in Stakeholders analysis in process External interface image 4 Expectations : SWE-2; s: SR-1, AR- 1, AR-2 EIR-2 payments through PayPal Users should be able to pay for coins (bought at MarketPlace) through PayPal. Major Goals 2.4, 3.4 and 4.3 in Stakeholders process ; Use case Virtual marketplace - payment with Paypal External interface image 5 Expectation: SE-5; s: MR-1, MR-2 Table 4 - External interface requirements 3.2. Mock-ups Image 1 - Dashboard. It is the main workstation for user. User must have quick access to the most important functionalities such as adding new coins to their collection or managing their collection. Dashboard must be easy to use and contain the right amount of info. The statistics bar at the top of the page is used to display information such as current value of the collection. Image 2- Virtual Marketplace. After searching for keywords the app generates a list of results that might be quite long. Using the filters one can narrow the search results further to find what they are looking for. The coins the user has browsed before and marked as of interest are specially marked with small stars to differentiate them from other search results. Image 3 - Mock up of overview or pending trades to be approved/rejected/countered in the Virtual Marketplace. This view is essential for the trading functionality as this is where the user will make their decision for trades or other transactions (buying /selling). As all transactions need two-sided approval before being completed. 15

15 Image 4 - Verification step that is required when creating and setting up an account. Each user has to verify itself by logging in to PayPal and validating its personal data. Image 6 - Payment with paypal. User can look up all coins listed for sale at Marketplace. Filtering and searching through categories and predefined parameters is also available (e.g search for coins, that are released after 2000; filter by origin country etc). Image 5. Coin editorial view. Users can edit in this view coin details or remove the coin from collection System requirements ID Statement Description Priority Source Support material Traceability SR-1 should have a Paypal integration using API For secure payments and trades the is integrated with Paypal verifying and payment infrastructure. Integration with PayPal API is updated regularly Major Function Mock-up Image 4 s: MR-1, AR-2, EIR- 1, EIR-2 SR-2 Coin database should be held in cloud based For easily accessible and secure database integration the coin database should be hosted Critical Functions ; Requireme CR-6, HR-3 16

16 database Table 5 - System requirements by cloud service such as Amazon. nt HR Data requirements Data requirements are supported by object/class diagram and state diagram in the appendices (diagrams and 4.2.3). The requirements are based on analysis of Hard data (described in the current analysis ). Diagram 14 - logical structure of data User - For the user of the mobile username is required. Collector - All mobile users are registered as coin collectors. Since we assume the collector at some point participates in coin trades (assumption SE- 8) the collector needs to input the following contact information: 1) Name of the collector; 2) Resident country; 3) address; 4) Ranking. Collection - Coin collection needs to have: 1) Collection name; 2) Collection owner (reference to collector); 3) Creation time. Trade - Each trade consists of coins in trade: 1) The coin has a specific owner collector The coin has a specific value The trade has also the following characteristics: Trade has starting point and ending point Trade has a result - confirmed/cancelled Trade has a status to indicate at what point of the trade is currently in progress: active, accepted, rejected, in progress, cancelled, confirmed (further details in state diagram) Trade has a type - either it s a financial trade (collector buys from other collector) or it s exchange of coins (one coin to another) Trade has participants who are also collectors at the same time. It needs to be distinguished which participator was the initiator of the trade. Coin A coin in the collection can have a lot characteristics which are important for assessing the coin s value. In the first scope of the project the coin should have the following data: Coin type (value) - for example: 10 cents or 20 cents etc Release country Release year Metal type Reference to standard catalog of world coins - (for example km#24) Diameter of the coin Estimated value Design description - free text at first Picture - not mandatory When coin is added to the collection we need to have additional data of the coin: To which collection the coin was added Time when was added to the collection Coin status in the collection (either ACTIVE; IN_TRADE; REMOVED - further details in state diagram) Location in collection - since mobile is just to support managing collection in real life - there still exist coin albums where all the coins are physically stored. Comment - freetext which can be added for any coin in the collection. For example High in emotional value or Will trade in 2 months etc. 17

17 3.4. Functional software requirements Authentication ID Statement Description Priority Source Support material Traceability AR-1 users to login with username and password The mobile enables log-in functionality for supporting logging in with a username and a password Every user have to create unique username Critical Goals: 8.1; 8.3; 9.2; 10.3 in Software expectation SW-1 EIR-1 AR-2 login with Paypal The mobile should have log-in functionality with Paypal authentication. Major Goals: 8.3; 9.2; 10. in Image 4 s: EIR-1, SR- 1 AR-3 setting up a new account for new user When creating a new user, mobile should set up a new user account By creating a new user, mobile system sets up following fields in database: username, password, personal data fields, coin collection fields. Critical Goals: 8.1 in Software expectation SW-1; Data requirements AR-4 Forgot password functionality when logged out If user forgets the password, the mobile should send the password to an e- mail, which the user provided when setting up an account. If user forgets the username, the mobile should send the username to an provided when signing up The that mobile sends, expires after 15 minutes when user does not use it for retrieving lost password or username. Table 6 - Functional software requirements - authentication Major Goals: 8.1; 8.3; 9.2 in Software expectation SW-2 18

18 Dashboard ID Statement Description Priority Source Support material Traceability DR-1 should enable profile management for users should have profile editor for user to manage their personal profile (profile details specified under Data requirements ) Users can set which personal information fields they can hide from public Users can change all the personal fields except username at all times Major Goals: 5.1, 6.1 in Data requirements DR-2 should have dashboard metrics with collection overall value should show the following metrics on the Dashboard: collection overall value The collection overall value is calculated, using only those coins values which value is added by coin s owner. Minor Goals 1.4, 6.2 in Mock-up image 1 DR-3 DR-3 should have dashboard metrics with number of coins in the collection should show the following metrics on the Dashboard: number of coins in the collection, collection value etc. User can set the preferred metrics via personal settings. Minor Goals 1.4, 6.2 in Mock-up image 1 DR-2 DR-4 should have shortlinks on dashboard should have shortlinks on dashboard main activities such as collection management and trading coins User can set the preferred shortlinks via personal settings option. Major Goal 1.4 in Mock-up image 1 Table 7 - Functional software requirements dashboard 19

19 Collection management ID Statement Description Priority Source Support material Traceability CR-1 creating a collection creating a collection where to add coins into. When creating a collection, user has to fill following fields: collection name, location, description (optional). Critical Use-case Create collection Class/obje ct diagram Expectation SE-3, SE-4 CR-2 should show list of coins in the collection. should show a list containing the coins that user has in the collection. In list view, every coin has following fields: name, image Critical Goals: 1.1; 1.4 in Coins in collection s in class diagram Derives from scenarios: S- 1, S-2 in process ; CR-3 search functionality from the collection The search function searching by keywords, collections names, release year (ranges), release countries and value ranges The search results should be displayed under the search keyword entry field after the user taps Search button If the search results do not fit in the screen the user should be able to scroll down until they reach the last searchresult entry. Major Goal: 1.4 in KAOS Responsib ility and operationa l diagram Expectation SWE-6 CR-4 to add new coins to the collection. the user to add new coins to the collection. When adding a new coin to the collection, user has to enter following requested fields: coin name, coin picture (user can choose, if scanned Critical Use-case Add new coin to collection Scenario S-1 ; KAOS Responsib ility and operationa l diagram Expectation SE-3 20

20 image or chosen from collective database), coin location in collection. Other fields are optional. CR-5 coin scan functionality when inserting a new coin If a coin that is being added to a personal coin database exists in the collaborative database taking a photo of the coin (both sides) should return possible matches of which the user chooses the correct (if there is a correct one) match If there are no matches in the collective database no matches are displayed Minor Goal: 1.4 in Scenario S-1 in process ; Coin in class diagram;k AOS Responsib ility and operationa l diagram CR-4 CR-6 should check added coin against collaborative coin database should check added coin against collaborative coin database in order to make new entries to the database If the coin is already available in collaborative database and certain fields do not correspond, mobile software will create a variable from this coin (same coin variation). If the coin is not already available in collaborative database, it will be added to it as a new entry. If coin is deleted from user s database, the coin remains in collaborative database. Major Goal: 1.4 in Use case - add coin to collectio; KAOS Responsib ility model s : CR-3, SR-2, HR-3 CR-7 to save the scanned coin picture to the coin s data to save the scanned coin picture to the coin s data For scanning the coin picture, user has to use mobile back-side camera, make a picture of coin and upload it to the Minor Goal: 1.4 in Data requireme nts CR-3 21

21 mobile. User has to enable access to the camera function from the mobile phone general settings. If the mobile phone settings are not enabling te camera access to the mobile, user can not use the scanning functionality. CR-8 to view coin details to view its details that have been inserted when the coin was added to collection User can look up all the details from personal coin list Other users can see what coins certain user have if these are not hidden from his/hers public profile. Critical Goal: 1.4 in Data requireme nts CR-9 removing the coin from the collection to remove coins from the collection If the coin is removed, the coin location is also freed and made available for new coins. If user removes the coin from the collection, it will not delete it from collaborative database if the coin was listed there. Major Goal: 1.4 in State diagram; Object/cla ss diagram CR-10 to send chosen coin for sale the user to send selected coin(s) for sale at the marketplace If the coin is selected for the sale, the coin status will change into selling and the coin will be listed automatically at Market place User can change the coin status from selling to active at any time Major Goals: 2.1; 2.2 in State diagram; Scenario S-3 in MR-3 22

22 (assuming when she/he is online and using the mobile ) CR-11 managing collection general details managing collection general details (data requirements): collection name, its status: public/hidden. Major Goal 1.4 in Coin in collection in object/clas s diagram CR-1 Table 8 - Functional software requirements - collection management s value estimation (analytic hierarchy process can be found in the Appendix): CR-1-18% of the value CR-2-18% of the value CR-3-4% of the value CR-4-23% of the value CR-5-2% of the value CR-6-8% of the value CR-7-1% of the value CR-8-8% of the value CR-9-7% of the value CR-10-7% of the value CR-11-3% of the value s cost estimation (analytic hierarchy process can be found in the Appendix): CR-1-5% of the cost CR-2-3% of the cost CR-3-6% of the cost CR-4-4% of the cost CR-5-24% of the cost CR-6-33% of the cost CR-7-9% of the cost CR-8-2% of the cost CR-9-4% of the cost CR-10-5% of the cost CR-11-4% of the cost Diagram 15 - Plot ROI graph of collection management requirements 23

23 Virtual marketplace ID Statement Description Priority Source Support material Traceability MR-1 payment with Paypal in the marketplace should enable payments with Paypal in the Marketplace by using the PayPal API extension. Integration between Paypal and mobile is regularly updated Major Goals: 2.4, 3.4, 4.3 in Scenarios S-3, S-4, S-5 in s EIR-2, SR-1 MR-2 buying coins from marketplace should enable to buy coins from marketplace from other users. User can buy only those coins that are listed for selling Critical Goals: 3.1, 3.2, 3.3, 3.4 in Mock-up image 2; Scenario S-5 in ; State diagram s EIR-2, SR-1, MR-3, MR-2, MR-5, MR-6. MR-3 to add coins for sale in marketplace should enable user to add the selected coin(s) for sale in the marketplace. If the coins are listed for selling, the coin will be seen automatically at Marketplace Critical Goals: 2.1, 2.2, 2.3, 2.4 in Mock-up image 2; Scenario S-3 in ; state diagram s MR-1, MR-2, MR-4, MR-5, MR-6, CR-10 MR-4 trade confirmation should enable trade confirmation Trade confirmation finalizes the trade with second party Critical Goals: 4.1, 4.2, 4.3 in Mock-up image 3 Scenarios S-3, S-4, S-5 in MR-5 to reject transaction in marketplace should enable to reject transaction When user does not want to proceed with the transaction, he/she can cancel it by selecting cancel transaction. Critical Goals: 4.1, 4.2, 4.3 in Mock-up image 3 Scenarios S-3, S-4, S-5 s MR-1, MR-3, MR-3, MR-4, MR-6, MR-7. MR-6 should notify parties of should notify parties of transaction results. There are two types of Major Scenario diagram s MR-4, MR-5 24

24 transaction results notifications: either confirmation or rejection MR-7 to rate other traders should enable adding ratings to other traders Ratings can be given only to those, with whom user has had transactions with Minor Goals 2.4, 3.4, 4.3 in Data requirements; user class diagram MR-8 MR-8 to view other traders profiles should enable viewing other traders profiles Other users can see only those fields that are not hidden by user setting preferences (made private ). Table 9 - Functional software requirements - marketplace Major Goals 2.4, 3.4, 4.3 in Data requirements; user class diagram MR Non-functional software requirements ID Type Statement Description Priority Source Traceability NF-1 Reliability full functionality should be accessible with Internet connection Without internet connection when the user opens the mobile they will see the most recent sync version only When a connection to the internet is established the mobile will sync with the data storage via Amazon Cloud The user can only make transactions while connected to the internet. Critical HR-3 NF-2 Security should use secure connection when connecting to the cloud The mobile can only connect to the server via an encrypted SSL connection Major Goals 2.4, 3.4, 4.3, 8.3, 9.2, 10.3 in SR-2 NF-3 Reliability system should delete non-verified accounts from the mobile database after 7 In order to verify an account the user needs to connect their account with paypal If after 7 days of creating the account the account hac not been connected with Paypal the account will be marked as not Major Goals 2.4, 3.4, 4.3, 8.3, 9.2, 10.3 in AR-2, AR-3, AR-4 25

25 days. active in the database Not active or un verified accounts cannot be used for any transactions After 7 days of account creation but no verification the mobile will show a message with instructions to the user how they can verify their account to keep using the NF-4 Safety should disable login functionality after 5 failed login attempts With each login there are 5 login attempts If the user enters their password incorrectly 5 times in a row the will offer the option to reset their password. For the resetting of the password a verification is sent to the address associated with the account within 5 minutes Major Goals 2.4, 3.4, 4.3, 8.3, 9.2., 10.3 in AR-4 NF-5 Safety only unique user names in the database For each account creating the database is cross checked if that username is already in the database If user creates an account and chooses a username that is already in use, mobile will display an error message for the to try another username The error message will be displayed each time a nonunique username is entered The cross check with the database should take no longer than 1 second Critical Goal 1.4 in Expectation SWE-1 NF-6 Performanc e should use cache for loading images and data Images and other data should load no more than 0,5 seconds Minor s CR-7, CR- 5 NF-7 Maintainab ility software should be updated regularly (at least 2 times a year) Table 10 - Non-Functional software requirements software should be updated regularly to maintain its functionalities Major Goals: 8.3, 9.2, 10.3 in 26

26 3.6. Hardware requirements ID Statement Description Priority Source Support material Traceability HR-1 should run on supported OPsystems should support following op.systems: Android , ios Critical Goals 8.1, 8.3, 9.2, 10.3 in Primary scope HR-2 device photographing functionality device should have a 2MP or higher resolution back-side (main) camera for scanning the coin. Major Data requirements s CR-5, CR-7 HR-3 should use amazon cloud to store data should use amazon cloud for data storage. Amazon cloud is only accessible when user is online (e.g user can access to coin collection only when using software system online). Critical Goals 1.4, 8.1, 8.3, 9.2, 10.3 in analysis in, SR-2 s SR-2, CR-6 Table 11 - Hardware requirements 3.7. s hierarchy Minor requirements requirements hierarchy. Diagram 16 - Minor requirements hierarchy 27

27 4. Appendices 4.1. Diagrams Class/object diagram Diagram 17- Class diagram of collectors, coins and trades. Collector object represents all collector roles (collection builder, seller, buyer, trader, socialite, exhibitor) (as described in analysis). Each collector has collection which consists of coins. Coin object represents all coins in the shared database. Coins and collections are connected by coinsincollection class which specifies which coins are in specific collections. Trades object represents all kinds of trades (buying, selling, trading), its participants and coins in trade (different types of trades described in scenarios). 28

28 4.1.2 State diagram Diagram 18 - State diagram of coins in collection and trades Coins in collection Coins in collection can have multiple statuses. When coin is added to the collection its status is set ACTIVE which means it s available in the collection and can be used for transactions. When coin is removed from the collection its status is set REMOVED and it cannot be accessed from the collection anymore. Although the coin s data still remains in the global coin database: just the link between coin and collection is removed. Coin in the collection can be sent for trading (either put up for sale or for trading), then coin s status is set IN_TRADE. If trade is successful then coin is removed from the collection; if trade is not successful (trade still ended), then coin s status is set back to ACTIVE in the collection. Trades When new trade is set up its status is set ACTIVE. Once counterparty has been found (or specifically referred to someone), then they can either accept or reject the trade. If trade is accepted then its status is set to ACCEPTED and after that IN_PROGRESS which states that further trade details are being agreed on, payments made and received. Once both parties are satisfied with the end result (payment or coin received) then trade s status is set to CONFIRMED which also ends the trading process. If counterparty rejects trade then trade status is set to REJECTED and trade cancelled. Trade s status is set to CANCELLED which also ends the trading process. 29

29 Scenario diagram Diagram 19 - Scenario diagram of a trade Scenario diagram describes the process of trading in the Marketplace. First of all one trader sends one coin for the collection for trading in the marketplace. Coin stays in the marketplace until an offer is made by another collector. After specifying details trade is accepted, payment done and coin sent. When both parties have gained expected result (received coin or payment) then trade is confirmed. 30

30 KAOS responsibility and operational diagram Image 6 - KAOS responsibility diagram The Responsibility diagram explores how a goal, in this case goal 1.1. Search and collect as many coins as possible within interest area - add new coins to collection, is reached and where which actors play a role. To fulfill the requirement of CR-3 System has a built-id scan functionality for easy recognition of the coin. User can scan the coin when adding it to the existing collection. Scanning takes a picture of the coin and checks it against the collaborative coin database. If there s a match coin detail fields are filled according to existing data; if not then the user can make a new entry to the collaborative database. the Software must complete the operations of checking the database for existing entries and return the findings to the entry interface respective fields Analytic Hierarchy Process Analytics hierarchy process for collection management requirements Value estimations CR-1 CR-2 CR-3 CR-4 CR-5 CR-6 CR-7 CR-8 CR-9 CR-10 CR-11 CR CR CR-3 1/9 1/9 1 1/9 5 1/3 7 1/3 1/3 1/5 3 CR CR-5 1/9 1/9 1/5 1/9 1 1/7 3 1/5 1/5 1/5 1/3 31

31 CR-6 1/5 1/5 3 1/ /3 5 CR-7 1/9 1/9 1/7 1/9 1/3 1/5 1 1/5 1/5 1/5 1/5 CR-8 1/3 1/3 3 1/5 5 1/ CR-9 1/3 1/3 3 1/5 5 1/3 5 1/ CR-10 1/3 1/3 5 1/ /3 1/3 1 5 CR-11 1/7 1/7 1/3 1/7 3 1/5 5 1/5 1/5 1/5 1 SUM Table 12 - s preferences CR-1 CR-2 CR-3 CR-4 CR-5 CR-6 CR-7 CR-8 CR-9 CR-10 CR-11 CR-1 0,21 0,21 0,21 0,24 0,15 0,22 0,14 0,18 0,16 0,14 0,15 CR-2 0,21 0,21 0,21 0,24 0,15 0,22 0,14 0,18 0,16 0,14 0,15 CR-3 0,02 0,02 0,02 0,03 0,09 0,01 0,11 0,02 0,02 0,01 0,07 CR-4 0,21 0,21 0,21 0,24 0,15 0,31 0,14 0,30 0,26 0,33 0,15 CR-5 0,02 0,02 0,00 0,03 0,02 0,01 0,05 0,01 0,01 0,01 0,01 CR-6 0,04 0,04 0,07 0,03 0,12 0,04 0,08 0,18 0,16 0,02 0,11 CR-7 0,02 0,02 0,00 0,03 0,01 0,01 0,02 0,01 0,01 0,01 0,00 CR-8 0,07 0,07 0,07 0,05 0,09 0,01 0,08 0,06 0,16 0,14 0,11 CR-9 0,07 0,07 0,07 0,05 0,09 0,01 0,08 0,02 0,05 0,14 0,11 CR-10 0,07 0,07 0,12 0,03 0,09 0,13 0,08 0,02 0,02 0,05 0,11 CR-11 0,07 0,03 0,01 0,03 0,05 0,01 0,08 0,01 0,01 0,01 0,02 Table 13 - Estimating the eigenvalues Sum Sum/11 CR ,18 CR ,18 CR ,04 CR ,23 CR ,02 CR ,08 CR ,01 32

32 CR ,08 CR ,07 CR ,07 CR ,03 Table 14 - Values for requirements Cost estimations CR-1 CR-2 CR-3 CR-4 CR-5 CR-6 CR-7 CR-8 CR-9 CR-10 CR-11 CR-1 1,00 3,00 3,00 1,00 1/7 1/9 1/3 3,00 1,00 1,00 1,00 CR-2 1/3 1,00 3,00 1/3 1/7 1/9 1/3 1,00 1/3 1/3 1/3 CR-3 1/3 1/3 1,00 3,00 1/7 1/9 1/3 5,00 3,00 3,00 3,00 CR-4 1,00 3,00 1/3 1,00 1/7 1/9 1,00 3,00 1,00 1,00 1,00 CR-5 7,00 7,00 7,00 7,00 1,00 1/3 7,00 7,00 7,00 7,00 7,00 CR-6 9,00 9,00 9,00 9,00 3,00 1,00 7,00 7,00 7,00 7,00 7,00 CR-7 3,00 3,00 3,00 1,00 1/7 1/7 1,00 5,00 5,00 5,00 5,00 CR-8 1/3 1,00 1/5 1/3 1/7 1/7 1/5 1,00 1/3 1/3 1/3 CR-9 1,00 3,00 1/3 1,00 1/7 1/7 1/5 3,00 1,00 1,00 1,00 CR-10 1,00 3,00 1/3 1,00 1/7 1/7 1/5 3,00 1,00 1,00 1,00 CR-11 1,00 3,00 1/3 1,00 1/7 1/7 1/5 3,00 1,00 1,00 1,00 SUM 25,00 36,33 27,53 25,67 5,29 2,49 17,79 41,00 27,67 27,67 27,67 Table 15 - s preferences CR-1 CR-2 CR-3 CR-4 CR-5 CR-6 CR-7 CR-8 CR-9 CR-10 CR-11 CR-1 0,04 0,08 0,11 0,04 0,03 0,04 0,02 0,07 0,04 0,04 0,04 CR-2 0,01 0,03 0,11 0,01 0,03 0,04 0,02 0,02 0,01 0,01 0,01 CR-3 0,01 0,01 0,04 0,12 0,03 0,04 0,02 0,12 0,11 0,11 0,11 CR-4 0,04 0,08 0,01 0,04 0,03 0,04 0,06 0,07 0,04 0,04 0,04 CR-5 0,28 0,19 0,25 0,27 0,19 0,13 0,39 0,17 0,25 0,25 0,25 CR-6 0,36 0,25 0,33 0,35 0,57 0,40 0,39 0,17 0,25 0,25 0,25 CR-7 0,12 0,08 0,11 0,04 0,03 0,06 0,06 0,12 0,18 0,01 0,18 CR-8 0,01 0,03 0,01 0,01 0,03 0,06 0,01 0,02 0,01 0,04 0,01 33

33 CR-9 0,04 0,08 0,01 0,04 0,03 0,06 0,01 0,07 0,04 0,04 0,04 CR-10 0,04 0,08 0,01 0,04 0,03 0,06 0,17 0,02 0,04 0,04 0,04 CR-11 0,04 0,08 0,01 0,04 0,03 0,06 0,01 0,07 0,04 0,04 0,04 Table 16 - Estimating the eigenvalues Sum Sum/11 CR-1 0,54 0,05 CR-2 0,31 0,03 CR-3 0,71 0,06 CR-4 0,48 0,04 CR-5 2,65 0,24 CR-6 3,58 0,33 CR-7 0,99 0,09 CR-8 0,24 0,02 CR-9 0,45 0,04 CR-10 0,56 0,05 CR-11 0,45 0,04 Table 17 - Costs for requirements 5. Perspectives In this chapter, we are making further suggestions for improving the mobile. These suggestions are handled as outside the primary scope. 1. Creating Premium state for user accounts. In primary scope we defined that user can add unlimited amount of coins to the database. In 1.1 release, mobile would increase the amount to 1000 coins (free account owners can then upload up to 1000 coins without charge). When upgrading to Premium state, user can get access to unlimited storage use. 34