People

2. People

3. Problem Domain • Consuming in the internet can be a hassle, especially when the desired product is made up of many different components with constraints between them • It is a time consuming process • A lot of pre knowledge of the consuming domain is needed

4. Current Situation • Most of the shopping websites offer you a basic and conservative way to shop • You enter, you search, if the website is nice enough you sort results, you enter another website, you search… Eventually it’s a loop!

5. Current Situation (Cont.)

6. Current Situation (Cont.)

7. Zap Problems • Too many results • Pre knowledge of the consuming domain is needed (i.e. computer expert) • The products in the results are the ones the resellers want you to buy and not necessarily the ones you need

8. Current Situation (Cont.)

9. Hunch Problems • The product is not built especially for your needs • The products in the results are the ones the resellers want you to buy and not necessarily the ones you need

10. PCB EXPERT SOLUTION • Our system will analyze the user’s input (character and preferences) • Will build a desired product while considering the user input and the constraints between the product’s components • Will respond with a list of products tailored for the costumer needs and character while benefiting from past knowledge of other costumers

11. System Architecture

12. 3 Major Components • GUI (User) – Web based • GUI (Management) – Web based • Web Service - Building the product (PCB Engine) and recommendation engine

13. Main Functional Requirements - User

14. Main Functional Requirements - User • Short and simple phase • Registered users will get more accurate results Registration

15. Main Functional Requirements - User • Registered users will be able to login to the service • User will be blocked after 3 unsuccessful tries for 20 minutes Login

16. Main Functional Requirements - User • Collect data from the user about the desired product • Data is collected in a form of questions • The purpose of this step is to analyze the user needs and understand his preferences Collect Desired Product Information

17. Main Functional Requirements - User • Collect characteristic information on the user such as: how technological he is, what kind of person he is etc. • Data is collected in a form of ratings • The purpose of this step is to analyze the user characteristics Collect Characteristic Information

18. Main Functional Requirements - User • Build a product from many different components while taking to measure the constraints between them, the user's preferences and the collected information of his characteristics • In this section our engine will build the optimal product and will present it for the user Building the Product for the User

19. Main Functional Requirements - User • Display additional products besides the product that is built by the PCB Engine • Will be built based on small differences and optimizations from the optimal product for example a 10% change in the budget Displaying Additional Products

20. Main Functional Requirements - User • Users will have the ability to give us feedback on the offered products and to mention which products they liked and willing to buy and which they did not • This data will help us recommend products to similar users based on this user's characteristic analysis Feedback

21. Main Functional Requirements - User • These products will be offered based on users with similar characteristics • The intersection between the list from the PCB engine and the list from the recommendation engine will empty Recommended Products

22. Components Management Main Functional Requirements - Management • User Management • Login • Components Constraints Management • Decision Tree Management

23. Non-Functional Requirements • Speed, Capacity & Throughput • Registration should take less than 1 minute • Login should take less than 30 seconds. • The decision tree step will take less than 2 minutes. • The character analysis step will take less than 2 minutes and will happen only once for registered users. • Building the desired product will take less than 5 minutes. • The application will take less than 50MB. • The data each item will take 30kb in average. • The data each user will take 50kb in average. • The system will handle up to 20 requests at the same time.

24. Non-Functional Requirements • Reliability • Daily backups for all the application's data. • The system will be fault tolerant. When a crash occurs, the server will re respond in minimal time. The user will get a message that the service is down. • Safety & Security • All the personal data will be secured. • The user passwords will be stored encrypted.

25. Non-Functional Requirements • Portability • The system will support all the popular web browsers: IE7 and up, Firefox3 and up, Chrome3 and up. • The application will run on a windows server. • The application will support Unicode encoding. • The interface language will be Hebrew. • The application will support input in Hebrew and English. • Availability • The hosting server and the web service should be available 99% of the time. • The user will be able to use our application anytime and anywhere that has a computer with internet access and one of the supported web browsers.

26. Non-Functional Requirements • Usability • The Website interface will be user friendly and very intuitive for users with low technological background. Most of the users of our system are simple users with no former knowledge about the consuming domain. • Learning the location of the main different features will take about 5 minutes. All the main features will be accessible in one click from the home page. • Learning how to use the main features will be simple and intuitive. The user will be able to explore these features and understand their functionality quickly. • The management system will be easy to use and very informative. • The management system learning curve will be steep. • Learning and understanding the usability and functionality of the management system will take about an hour.

27. Use Cases Overview

28. Major Use Cases Use Case 3 – Insert Characteristic Info Name: Insert Characteristic Info Pre -Condition: The system web server is up and running, the user is logged in. Post-Condition: The characteristic data was added to the system.

29. Major Use Cases Use Case 4 – Answer Decision Tree Questions Name: Answer Decision Tree Questions Pre -Condition: The system web server is up and running, the system initialized the decision tree. Post-Condition: The data was added to the system.

30. Major Use Cases Use Case 5 – Build Product Name: Build Product Pre -Condition: The system web server is up and running, the user is logged in. Post-Condition: The system web service will respond with the relevant products according to the user characteristic and preferences.

31. Risks • Usage of new frameworks – in order to implement this project correctly we will have to use some frameworks (.Net) that are new and advanced but also have a learning curve • GUI Design – GUI wise, we will need to consider serious usability issues. If, after creating the GUI, we will find serious usability issues than we will have to consider making some changes in it • Algorithms – our algorithms need to be adapted by the domain model and content. In late stages of the development we might have to revise the way the system works

32. Q&A Any Questions?