Department of Software Engineering National University of Computer and Emerging Sciences, Chiniot-Faisalabad Campus E-COMMERCE PLATFORM REQUIREMENTS PROJECT PHASE-03 INSTRUCTOR: Sir Sajid Anwar Group Members: Name Section Roll No Ibrahim Faisal BSE-3B 22F-3702 Furqan Asghar BSE-3B 22F-3693 Ramis Ali BSE-3B 22F-3703 2 E-Commerce Platform Requirements Document Contents Requirements Elicitation Technique: .............................................................................................. 4 Reasons: ...................................................................................................................................... 4 1) Complexity of the business: ......................................................................................... 4 2) Distributed Nature of Stakeholders: ............................................................................ 4 3) Need for Traceability: ................................................................................................... 4 4) Improved Communication: ........................................................................................... 4 5) Reduce Time and Cost: ................................................................................................. 4 6) Link to our System: ....................................................................................................... 4 7) Example: ....................................................................................................................... 5 Requirement Specification in Natural Language: ........................................................................... 6 1. Functional Requirements: .................................................................................................... 6 2. Non-Functional Requirements:............................................................................................ 8 a) Usability: ....................................................................................................................... 8 b) Reliability: ..................................................................................................................... 8 c) Availability: ....................................................................................................................... 8 d) Efficiency:...................................................................................................................... 8 Requirement Specification using Use Case Models: ...................................................................... 9 Requirement Specification Using Use Case Specification: ........................................................... 10 Use Case Specification: 01 ........................................................................................................ 10 Use Case Specification: 02 ........................................................................................................ 12 Use Case Specification: 03 ........................................................................................................ 14 Use Case Specification: 04 ........................................................................................................ 16 Use Case Specification: 05 ........................................................................................................ 18 Requirement Analysis Using QVscribe Tool: ................................................................................. 20 Requirement Analysis Using QuARS Tool: .................................................................................... 23 Goal Model:................................................................................................................................... 26 Requirement Prioritization – Weiger’s Prioritization Matrix:....................................................... 27 3 E-Commerce Platform Requirements Document Requirement Prioritization – Analytical Hierarchy Process (AHP): .............................................. 28 Market Perspective: .................................................................................................................. 29 Matrix: ................................................................................................................................... 29 Normalized: ........................................................................................................................... 30 Priority Vector: ...................................................................................................................... 31 Income Perspective:.................................................................................................................. 32 Matrix: ................................................................................................................................... 32 Normalized: ........................................................................................................................... 33 Priority Vector: ...................................................................................................................... 34 References: ................................................................................................................................... 35 4 E-Commerce Platform Requirements Document Requirements Elicitation Technique: Document-Centric Technique for eliciting requirements for E-Commerce Platform. Reasons: 1) Complexity of the business: An e-commerce platform is a complex system with multiple components, interfaces, and stakeholders. The document-centered technique can help break down the system into smaller, manageable parts, making it easier to understand and analyze the requirements. 2) Distributed Nature of Stakeholders: In an e-commerce platform, stakeholders can be distributed across different locations, making it difficult to gather requirements through traditional methods like interviews or workshops. Documents can be shared easily, allowing stakeholders to review and provide feedback at their convenience. 3) Need for Traceability: The document-centered technique provides a clear traceability of requirements, which is essential in a complex system like an e-commerce platform. This ensures that all requirements are accounted for, and any changes or updates can be easily tracked and implemented. 4) Improved Communication: The document-centered technique can improve communication between stakeholders by providing a shared language and understanding of the system. This can help reduce misunderstandings and errors, which can be costly in a complex system like an e-commerce platform. 5) Reduce Time and Cost: The document-centered technique can save time and cost by reducing the need for multiple meetings, workshops, and interviews. It also helps avoid errors and miscommunications, which can lead to costly rework or delays in the project. 6) Link to our System: As there are many online E-Commerce Platform online which are working good and have a good user involvement and usability. We are using a document of such platform to elicit requirements for our system. That platform is “E-Kharidari”.i 5 E-Commerce Platform Requirements Document 7) Example: Amazon: Amazon's e-commerce platform is one of the most successful examples of a document-centered approach. They use a variety of documents, such as user manuals, technical guides, and design specifications, to gather requirements and ensure that their system meets the needs of their stakeholders.ii Google: Google's search engine algorithm is another example of a document-centered approach. They use a variety of documents, such as design documents, technical specs, and user guides, to gather requirements and ensure that their algorithm meets the needs of their users.iii Airbnb: Airbnb's platform is another example of a document-centered approach. They use a variety of documents, such as user stories, technical specifications, and design guidelines, to gather requirements and ensure that their platform meets the needs of their stakeholders.iv 6 E-Commerce Platform Requirements Document Requirement Specification in Natural Language: 1. Functional Requirements: ID Description FR-1 The system shall allow user to sign-up/register via Email along with password by providing some specific details about him/her for the account to register on the application. FR-2 The system shall allow user to login via username along with password on the application. FR-3 The system shall allow user to login via biometric on the application. FR-4 User can search the product of specific category. FR-5 User can view the product of specific category. FR-6 User can order the product. FR-7 User can view the profile. FR-8 System will provide recommendations on the basis of past purchases. FR-9 The customer/user after ordering shipment, should be able to cancel the order. FR-10 The mode of payment is cash on deliver but we’ll extend it to credit card, debit card etc. in future. FR-11 The user can logout from application. FR-12 After placing the order, the system will have to send the copy of bill to customer’s/user’s Email. FR-13 After the order has been placed, the customer/user should be able to track the location status of the system. 7 E-Commerce Platform Requirements Document FR-14 Admin should be able to view the location of the shipment. FR-15 Admin will assign the shipment to courier service. FR-16 Courier Service will be able to change the payment status after shipment is delivered. FR-17 Courier Service will be able to view the shipments to deliver. 8 E-Commerce Platform Requirements Document 2. Non-Functional Requirements: a) Usability: The system will give a simple graphical user interface, and easily learnable. Any warning or error message created by application will be clear, brief, affable, and free of language. b) Reliability: The system should be reliable. If any error occurs then it should maintain itself within 15 seconds. User should have an alternate option such as reload or refresh the system in case of any problem. c) Availability: System will be available 24/7 so the user can use it at any time. d) Efficiency: System response time should be less than 30 seconds and resource utilization must be low. 9 E-Commerce Platform Requirements Document Requirement Specification using Use Case Models: E-Commerce Platform Requirements Document 10 Requirement Specification Using Use Case Specification: Use Case Specification: 01 Nr. Section Explanation 1 Designation UC 00-01 2 Name Search Product 3 Person Responsible Ibrahim Faisal 4 Description User will search the product tin which he/she is interested by its name. 5 Trigger Event The User wishes to search the product. 6 Actors Customer/User 7 Pre-Conditions 8 Post-Conditions User will view the searched product and can search more products. 9 Main Scenario 1. User clicks on the search bar on the homepage of the ecommerce website. 2. User enters the name of the product he/she is interested in. 3. AI assistant searches the product database for the entered product name. 4. AI assistant displays a list of relevant products on the search results page. 5. User selects the desired product from the search results. 6. User is redirected to the product detail page. 10 Alternative Scenario 5. User didn’t find the desired product. User should be registered. User should be logged in. The product database is available and up-to-date. 5.1 User selects one of the suggested products. 11 Exception Scenario 2. User enters an invalid or misspelled product name. 2.1. AI assistant displays an error message or suggests 11 E-Commerce Platform Requirements Document corrections to the user. 2.2. User corrects the product name and tries the search again. 12 Result User receives a list of relevant products on the search results page. 13 Criticality High - The search function is a critical component of the ecommerce website, and users expect accurate and relevant search results. E-Commerce Platform Requirements Document 12 Use Case Specification: 02 Nr. Section Explanation 1 Designation UC 00-02 2 Name View Recommendations 3 Person Responsible Ibrahim Faisal 4 Description System will provide recommendations on the basis of past purchases. 5 Trigger Event The User wishes to search the product. 6 Actors Customer/User, System 7 Pre-Conditions 8 Post-Conditions User will view the searched product and can search more products. 9 Main Scenario 1. The user logs into the system. 2. The system identifies the user based on their credentials. 3. The system accesses the user's purchase history from the database. 4. The system analyzes the purchase history data to identify the user's preferences, such as product categories, brands, or types of products. 5. The system generates product recommendations based on the user's preferences. 6. The system displays the product recommendations to the user. 10 Alternative Scenario 4.1) If the user has an incomplete or limited purchase history, the system may request additional preferences or suggest exploring popular products. The user is registered and logged into the system. The user has a history of past purchases. The purchase history database is up to date and accurate. 4.2) If the user explicitly indicates that they do not want to 13 E-Commerce Platform Requirements Document receive recommendations, the system should respect this preference and not display recommendations. 11 Exception Scenario If there are technical issues with accessing the purchase history or generating recommendations, an error message is displayed, and the user is informed that recommendations are currently unavailable. 12 Result The user is presented with product recommendations tailored to their past purchase history and preferences, enhancing their shopping experience. 13 Criticality High - This use case is of high importance for enhancing user engagement and driving sales, as it improves the user experience and increases the likelihood of repeat purchases. 14 E-Commerce Platform Requirements Document Use Case Specification: 03 Nr. Section Explanation 1. Designation UC 00-03 2. Name The system shall allow user to login via username along with password on the application. 3. Personal Responsible Furqan Asghar 4. Description This use case describes the steps and interactions involved in a user logging into the application using their username and password. 5. Trigger Event The user initiates the login process. 6. Actor User 7. Pre-Condition The user has registered an account in the application. The user has a valid username and password. 8. Post-Condition The user is successfully logged into the application. 9. Main Scenario 1. The user launches the application. 2. The application presents the login screen. 3. The user enters their username and password. 4. The system validates the entered username and password. a. If the entered username and password are correct, the system proceeds to Step 5. b. b. If the entered username and password are incorrect, the system displays an error message and allows the user to reenter their credentials. Return to Step 3. 5. The system logs the user into the application. 6. The application presents the user with access to their account and its features. 7. The user can now interact with the application as a logged-in user. 1. If the user forgets their password, they can select a "Forgot Password" option, which will guide them through the process of resetting their password. 2. If the user doesn't have an account, they can select a "Sign Up" option, which will guide them through the registration process. 10. Alternative Scenario 15 E-Commerce Platform Requirements Document 11. Exception Scenario 12. Result 13. Criticality 3. If there are technical issues such as network problems or server unavailability, the system will display an appropriate error message and allow the user to retry. If the user repeatedly enters incorrect credentials and exceeds a predefined number of login attempts, the system may lock the user's account for a specified duration to prevent unauthorized access. The user should be informed of this action. Successful login results in the user gaining access to their account and the application. Unsuccessful login results in the user being informed of the failure and returned to the login screen. This use case is critical for the application's functionality as it is the primary method for user authentication and access to the application's features. 16 E-Commerce Platform Requirements Document Use Case Specification: 04 Nr. Section Explanation 1. Designation UC 00-04 2. Name Order Product 3. Personal Responsible Furqan Asghar 4. Description The user/customer can order product. 5. Trigger Event The user initiates the order process 6. Actor Primary: User Secondary: Payment Gateway (to process payments) 7. Pre-Condition 8. Post-Condition 9. Main Scenario 1. The user is logged into their account. The user has selected a product they want to purchase. The selected product is in stock and available. The product is added to the user's order history. Payment is processed successfully. The order is confirmed. The user navigates to the product catalog and selects a product they want to order. 2. The user adds the selected product to their shopping cart. 3. The user reviews the items in the shopping cart. 4. The user proceeds to checkout. 5. The system checks the product inventory to ensure it's available. 6. If the product is unavailable or out of stock, the system informs the user and removes the product from the cart. 7. If the product is available, the user provides the shipping address and payment information. 8. The user confirms the order. 9. The system processes the payment transaction through the Payment Gateway. 10. Upon successful payment, the product is marked as purchased and added to the user's order history. 11. The user receives an order confirmation with details. 17 E-Commerce Platform Requirements Document 10. Alternative Scenario 11. Exception Scenario 12. Result 13. Criticality In step 6, if the product is unavailable, the user may choose to remove the product from the cart or be placed on a waitlist if that feature is available. In step 8, if the user decides to cancel the order before confirming, the system cancels the order process. If there are issues with processing the payment (e.g., declined credit card), the system notifies the user and provides guidance on resolving the payment issue. Successful completion of this use case results in the user placing an order for the selected product, payment being processed, and an order confirmation being provided. In case of an issue, the user is informed of the problem, and the order process is either canceled or placed on hold. This use case is essential for the core functionality of the application, as it involves the primary action of users purchasing products through the platform. 18 E-Commerce Platform Requirements Document Use Case Specification: 05 Nr. Section Explanation 1. Designation UC 00-05 2. Name Cancel Order 3. Personal Responsible Ramis Ali 4. Description The customer/user after ordering shipment, should be able to cancel the order. 5. Trigger Event The customer/user initiates a request to cancel a shipment order, either through the system's user interface or by contacting customer support. 6. Actor User 7. Pre-Condition The customer/user has an active account on the system. The customer/user has placed a shipment order. The shipment order is in a cancellable state (e.g., not yet shipped). 8. Post-Condition The shipment order is marked as "Cancelled" in the system. If applicable, a refund has been initiated. The customer/user receives confirmation of the order cancellation. The customer/user may receive follow-up communication or information regarding the refund process, if applicable. 9. Main Scenario 1. The customer/user logs into their account on the system. 2. The customer/user navigates to the order history or shipment order section. 3. The customer/user selects the specific order they wish to cancel. 4. The system verifies the order's current status to ensure it is eligible for cancellation (e.g., not yet shipped). 5. The system marks the order as "Cancellation Pending." 6. The system sends a notification to the customer/user confirming 19 E-Commerce Platform Requirements Document the request for cancellation. 7. The system updates the order status as "Cancelled." 8. If payment has been made, the system initiates the refund process (if applicable). 9. The customer/user receives a confirmation message or email that the order has been successfully cancelled. 10. Alternative Scenario 3.1) If the customer/user cannot find the order they wish to cancel, they may contact customer support for assistance. 4.1) If the order is not in a cancellable state (e.g., already shipped), the system informs the customer/user that cancellation is not possible and provides information on possible alternatives (e.g., returning the product). 11. Exception Scenario If the system encounters issues with processing a refund, it informs the customer/user about the situation and provides information on the resolution process. If the customer/user encounters difficulties in navigating the system or initiating the cancellation, they may contact customer support for assistance. 12. Result 13. Criticality This use case is of high importance as it directly affects the customer's ability to modify or cancel a shipment order, potentially impacting their satisfaction with the service. The customer/user has successfully cancelled the shipment order. If a refund is applicable, it has been initiated. The order status is updated to "Cancelled." 20 E-Commerce Platform Requirements Document Requirement Analysis Using QVscribe Tool: 1. The system shall allow user to sign-up/register via Email along with password by providing some specific details about him/her for the account to register on the application. Correctness: The requirement is not clear on the exact details that need to be provided for registration. It should specify what mandatory and optional fields are needed. Completeness: More contexts are needed on the overall registration/signup process and workflows. It does not specify things like validation of email, confirmation process, and login after registration etc. Consistency: The terms "sign-up" and "register" are used interchangeably which can cause confusion. One term should be used consistently. Unambiguity: "Some specific details" is ambiguous. The exact details needed for registration need to be clearly specified. 2. The system shall allow user to login via username along with password on the application. Correctness: It is not clear if username is collected during registration or customized later. Completeness: Details like validation of credentials, forgotten password workflows etc. are missing. Consistency: Does not specify if username is same as email used during registration. Unambiguity: Words like "login" and "application" can be better defined. 3. User can search the product of specific category. Correctness: It is not clear what can be searched - product name, description etc. The search criterion is ambiguous. Completeness: Details like how the categories are defined, search result outputs are missing. Consistency: Terms like "product" and "category" need to be properly defined for the context. Unambiguity: Words like "search" and "specific category" need more clarity. 4. User can view the product of specific category. Correctness: It is not clear what exactly can be viewed under a category (just images, names or full details?). The category criteria (top-level, sub-category etc.) is not defined Completeness: Category browsing/filtering workflows are missing. Product listing details (images, specifications etc.) are not mentioned. Paging/sorting of long lists is not accounted for 21 E-Commerce Platform Requirements Document 5. 6. 7. 8. Consistency: "Category" and "Product" terms need to be properly defined in the context. Expected structure and taxonomy of categories is ambiguous Unambiguity: "View" can mean different things like browsing, searching etc. "Specific category" criteria is vague User can order the product. Correctness: It is not clear what exactly is involved in ordering - adding to cart, payment, delivery etc. Completeness: The entire ordering workflow is missing - items selection, checkout, payment options, order confirmation. Edge cases like inventory checks are not considered Consistency: "Order" can have different meanings in different contexts and needs defining. Terms like "product" need attributes defined Unambiguity: Individual steps in the process are vague e.g. what does "order" entail User can view the profile. Correctness: It is not clear what information will be displayed on the profile. Completeness: Details of profile sections/fields are missing. Functionality like updating profile is not covered Consistency: "Profile" is not defined in the context of the system Unambiguity: "View" can have different meanings like view details, view profile summary etc. System will provide recommendations on the basis of past purchases. Correctness: The criteria/algorithm for recommendations is not defined. It is not clear how past purchases data will be collected/stored. Completeness: Triggers/places for recommendations are missing. User control over recommendations is not considered. Consistency: "Recommendations" and "past purchases" needs definitions. Data flow and sources are ambiguous. Unambiguity: Basis of recommendations is unclear. Expectations for users are vague. The customer/user after ordering shipment, should be able to cancel the order. Correctness: Timelines and conditions for order cancellation are unclear. Completeness: Cancellation process and workflows are missing. Impact of cancellation on stock/billing is not covered Consistency: Terms like "order", "shipment" need definitions. Unambiguity: It is vague what "after ordering shipment" implies. User/system interactions during cancellation are unclear 22 E-Commerce Platform Requirements Document 9. The mode of payment is cash on deliver but we’ll extend it to credit card, debit card etc. in future. Correctness: Current and future states are mixed, causing confusion. No clarity on timelines for additional payment options Completeness: Details of existing COD and future card payments are missing. Integration with payment gateways is not covered Consistency: "Cash on delivery", "Credit card" terms need to be defined. Unambiguity: Phrasing "we'll extend in future" is vague on when and how. Expectations for users over time are unclear 10. The user can logout from application. Correctness: The exact logout process is unclear. Impact of logout like clearing session is not defined. Completeness: Triggers for logout like menu option are missing. Security aspects are not covered Consistency: "Logout" is not defined in the context. Unambiguity: Expectations from logout are vague. 23 E-Commerce Platform Requirements Document Requirement Analysis Using QuARS Tool: 1. After placing the order, the system will have to send the copy of bill to customer’s/user’s Email. Acceptability: No clarification on format of bill copy sent via email. Accessibility of bill for users with disabilities is not considered. Robustness: Scenarios when email sending fails are not covered. No validation mentioned on correctness of customer email Safety: Data protection and privacy aspects not addressed. Security of communication channel not specified. Usability: Expected user experience after order placement is missing. Manual effort involved in bill generation/email sending. 2. After the order has been placed, the customer/user should be able to track the location status of the system. Acceptability: It is unclear what location details will be shared with users. Robustness: Edge cases like delayed updates are not considered. Third party integrations for location are not addressed. Safety: Privacy and data protection concerns while sharing locations. Information security for accessed location systems. Usability: Smooth experience across devices is not mentioned. Visualization of location progress is vague. 3. Admin should be able to view the location of the shipment. Acceptability: Privacy and consent for sharing live locations is not addressed. Robustness: Access controls and logs for admin access are not defined. Errors or delays in location updates are not covered. Safety: Information security controls for location APIs/systems. Data protection for customers' live/historical locations. Usability: Experience across devices is not mentioned. Visualization and filtering options are vague. 4. Admin will assign the shipment to courier service. Acceptability: User interface for assignment is not defined. Accessibility for admins with disabilities is not considered. Robustness: Error handling for invalid assignments is missing. Corner cases of delays/change of courier not covered. Safety: Data access controls for admin user roles. Information security for courier integration endpoints. Usability: Experience across devices is not mentioned. Workflows to notify courier/track assignment missing. 24 E-Commerce Platform Requirements Document 5. Courier Service will be able to change the payment status after shipment is delivered. Acceptability: Data and interface access for multiple couriers not defined. Customer notification on status changes is missing. Robustness: Error handling when status is invalid is not considered. Race conditions of concurrent status updates are not addressed. Safety: Information security of courier integrations/APIs. Data access controls and logs for status changes. Usability: Cross-device experience for courier partners not specified. Expected interactions to mark delivery not defined. 6. Courier Service will be able to view the shipments to deliver. Acceptability: Data accessibility for different types of couriers is not defined. Experience across different devices is unclear. Robustness: Error handling when invalid shipments are assigned is not covered. Race conditions of concurrent access not considered. Safety: Strong access controls for courier user authentication. Securing customer data accessed by third parties. Usability: Interfaces to view, filter shipments are not specified. Orientation across landscape/portrait modes vague. 7. The system will give a simple graphical user interface, and easily learnable. Any warning or error message created by application will be clear, brief, affable, and free of language. Acceptability: Accessibility for varied user needs and contexts is not specified Robustness: Graceful degradation of UI in limited bandwidth scenarios. Safety: Information and resource security aspects of UI code/components. Privacy design considering sensitive user information. Usability: User testing and iteration of design is not mentioned. Customization for varied user preferences is unclear 8. The system should be reliable. If any error occurs then it should maintain itself within 15 seconds. User should have an alternate option such as reload or refresh the system in case of any problem. Acceptability: Impact of errors on different user groups is not considered. Multidevice support during errors is ambiguous. Robustness: Error categories and escalation protocols are missing. Fallback strategies in case of persistent issues are not defined Safety: Information security controls during error scenarios. Preventing exposure of sensitive data after errors 25 E-Commerce Platform Requirements Document Usability: Visual indication of ongoing recovery process. Consistent UX for recovery actions across surfaces. 9. System will be available 24/7 so the user can use it at any time. Acceptability: Downtime SLAs for different regions/user groups is not defined. Communication for planned maintenance is unclear. Robustness: Failover strategies during outages/disasters are not covered. Monitoring and alarms for early warnings missing. Safety: Data backups and protection during incidents/downtime. Prevention of technical/security issues impacting uptime. Usability: Degraded functionality or offline modes not specified. Communication on interruptions and resolutions vague. 10. System response time should be less than 30 seconds and resource utilization must be low. Acceptability: Different response time SLAs for critical vs. non-critical functions is not defined. Performance experienced by users on varied network types is unclear. Robustness: Fallback mechanisms when performance degrades are not specified. Thresholds for escalation and load shedding are ambiguous. Safety: Security best practices to prevent attacks exploiting performance. Privacy protection of user/transaction data during degradation. Usability: Visually distinct indication of ongoing operations is missing. Consistent experience across platforms during overload. 26 E-Commerce Platform Requirements Document Goal Model: 27 E-Commerce Platform Requirements Document Requirement Prioritization – Weiger’s Prioritization Matrix: Relative 2 1 1 0.5 (Weight Benefit) (Weight Penalty) (Weigh Cost) (Weight Risk) Relative Relative Benefit Penalty Sign up/in 7 5 Search Product 4 View Product Weight Value Relative Cost Relative Risk % Cost % Risk % 19 14.8 5 14.7 3 2 10 7.8 3 8.8 3 2 8 6.6 2 Order Product Payment 3 1 7 5.5 9 6 24 Order Receipt 4 2 Track Order 2 Admin assign Shipment to courier services Requirements Total Priority Rank 11.1 0.731 2 2 7.4 0.624 5 5.9 3 11.1 0.576 6 1 2.9 4 14.8 0.534 8 18.8 6 17.7 1 3.7 0.962 1 10 7.8 3 8.8 3 11.1 0.534 8 2 6 4.7 2 5.9 2 7.4 0.490 9 4 1 9 7 3 8.8 2 7.4 0.560 7 Payment status updated 4 7 15 11.7 4 11.8 3 11.1 0.674 4 Product recommendation 7 6 20 15.6 5 14.7 4 14.8 0.706 3 Total 47 34 128 100 34 100 27 100 ---- ---- 28 E-Commerce Platform Requirements Document Requirement Prioritization – Analytical Hierarchy Process (AHP): R1 Sign up/in R2 Search Product R3 View Product R4 Order Product R5 Payment R6 Order Receipt R7 Track Order R8 Admin assign Shipment to courier services R9 Payment status updated R10 Product recommendation 29 E-Commerce Platform Requirements Document Market Perspective: Matrix: Market R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R1 1 3 2 2 3 2 3 2 3 1 R2 1/3 1 1/2 1/2 2 1 2 1 2 1/3 R3 1/2 2 1 1 2 1 2 1 2 1/2 R4 1/2 2 1 1 2 1 2 1 2 1/2 R5 1/3 1/2 1/2 1/2 1 1/2 2 1/2 2 1/3 R6 1/2 1 1 1 2 1 2 1 2 1/2 R7 1/3 1/2 1/2 1/2 1/2 1/2 1 1/2 2 1/3 R8 1/2 1 1 1 2 1 2 1 2 1/2 R9 1/3 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1 1/2 R10 1 3 2 2 3 3 3 2 3 1 30 E-Commerce Platform Requirements Document Normalized: Market R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R1 0.13 0.32 0.25 0.25 0.267 0.25 0.29 0.25 0.26 0.125 R2 0.03 0.08 0.08 0.09 0.2 0.08 0.2 0.09 0.2 0.03 R3 0.04 0.16 0.08 0.07 0.13 0.08 0.13 0.06 0.13 0.06 R4 0.04 0.16 0.08 0.06 0.2 0.08 0.2 0.09 0.2 0.09 R5 0.03 0.08 0.08 0.08 0.06 0.125 0.13 0.07 0.2 0.03 R6 0.04 0.08 0.8 0.08 0.13 0.08 0.13 0.08 0.13 0.06 R7 0.03 0.08 0.08 0.08 0.06 0.08 0.06 0.08 0.2 0.3 R8 0.04 0.08 0.08 0.08 0.13 0.08 0.13 0.08 0.2 0.06 R9 0.03 0.08 0.08 0.08 0.06 0.04 0.04 0.04 0.06 0.03 R10 0.06 0.32 0.25 0.16 0.26 0.25 0.29 0.25 0.26 0.125 31 E-Commerce Platform Requirements Document Priority Vector: R1 0.065 R2 0.064 R3 0.095 R4 0.19 R5 0.18 R6 0.095 R7 0.078 R8 0.055 R9 0.070 R10 0.108 32 E-Commerce Platform Requirements Document Income Perspective: Matrix: Income R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R1 1 4 3 3 4 3 4 3 4 2 R2 1/4 1 1/2 1/2 3 1 3 1 3 1/4 R3 1/3 2 1 1 2 1 2 1 2 1/3 R4 1/3 2 1 1 3 1 3 1 3 1/2 R5 1/4 1/3 1/3 1/3 1 1/2 2 1/2 3 1/4 R6 1/3 1 1/2 1/2 2 1 2 1 2 1/3 R7 1/4 1/3 1/3 1/3 1/2 1/2 1 1/2 3 1/4 R8 1/3 1 1/2 1/2 2 1 2 1 3 1/3 R9 1/4 1/3 1/3 1/3 1/3 1/3 1/3 1/2 1 1/4 R10 2 4 3 2 4 3 4 2 4 1 33 E-Commerce Platform Requirements Document Normalized: Income R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R1 0.12 0.24 0.16 0.18 0.18 0.18 0.2 0.18 0.2 0.15 R2 0.13 0.06 0.04 0.04 0.12 0.04 0.12 0.04 0.12 0.03 R3 0.04 0.12 0.08 0.09 0.06 0.09 0.08 0.09 0.06 0.04 R4 0.04 0.12 0.08 0.09 0.12 0.09 0.12 0.09 0.18 0.04 R5 0.13 0.04 0.04 0.04 0.06 0.09 0.12 0.09 0.18 0.03 R6 0.04 0.06 0.04 0.04 0.09 0.06 0.08 0.06 0.12 0.04 R7 0.13 0.04 0.04 0.04 0.06 0.06 0.04 0.06 0.18 0.03 R8 0.04 0.06 0.04 0.04 0.09 0.06 0.08 0.09 0.18 0.04 R9 0.13 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.06 0.03 R10 0.17 0.24 0.16 0.12 0.18 0.16 0.2 0.18 0.2 0.15 34 E-Commerce Platform Requirements Document Priority Vector: R1 0.165 R2 0.084 R3 0.088 R4 0.099 R5 0.078 R6 0.073 R7 0.074 R8 0.071 R9 0.061 R10 0.204 E-Commerce Platform Requirements Document 35 References: i https://e-kharidari.com/ ii https://www.amazon.com/ iii www.google.com iv https://www.airbnb.com/