Rainbow Fish: Your friends ask you to develop a website for their business during dinner at their new restaurant. The web site should include common advertising information like special events, hours, location, social media with reviews, and menu. At some point in the future, they would like to include an ability to make reservations, show daily specials, and take carryout orders on-line. The owners want to trade you free dinners for your development work. Functional Requirements: What user can see and interact with 1. As a customer I would like the background color to not distract me from the actual information 2. Transaction corrections, adjustments and cancellations 3. As a consumer I would like the information available to be correct, this includes hours, prices, menu items, and events. 4. As a customer I would like to see pictures of all the main dishes 5. As a customer I would like to see a calendar with all the special events and have the option to add the ones I like to my personal calendar. 6. As a manager/user I would like the ability to easily make changes to the website. 7. As a manager/user I want accessibility to view the algorithms of the website, this includes things like number of viewers and clicks. 8. As a customer I would like to have a live chat to answer my questions about the restaurant. 9. As a customer I would like to sign up for newsletters to receive emails about any deals or special events. Future Add ons 10. As a customer I would like the web application to accept my order and text/email confirmation. 11. As a customer I would like the website to be able to accept payment. 12. As a customer I would like the website to produce a receipt. 13. As a customer I would like to know that my personal information is safe and secure and wouldn't be jeopardized 14. As a manager I would like the website to develop weekly, monthly, and yearly reports about the sales. 15. As a customer I would like the website interface to function properly with a mobile web browser. Non-Functional Requirements: important, user doesn't interact with directly 1. Website should load within 5 seconds. This is important because the users will have a better experience with the website. For every second the site takes to load can decrease customer satisfaction. 2. The system should be capable of handling thousands of users without affecting its performance. This is necessary for efficiency and easy access. 3. Accommodate for future add ons, the system should be adaptable so it can handle future services easily. This is important to avoid future problems when making those changes. It's now time for you to design the system, based on the requirements you produced in the Requirements Activity. Choose 8-10 requirements. If your requirements were too far-ranging for this stage, you may modify them. List which requirements you will be using as the basis for this design. You (the group) are the software architect / technical lead for this project. You need to produce a design document containing the system architecture and detailed design for the system modules. Provide the necessarily diagrams and descriptions following the guidelines below and an example in the Appendix, Lecture notes and Sommerville Chapters 5 and 6. Deliverable: Your design diagrams and description in a single MS Word or PDF document _Design.doc Rubrics: a) Introduction (5 pts) b) Architecture (20 pts) c) Modules (25 pts) . 0 Your key task is to create a design document that contains the following deliverables: A. Introduction (10 pts) Project title Purpose of the design document What is this document about and who are the intended users of the document? What is the product you will be implementing? Who are the product's customers and users? Who created / initiated this project (i.e. who is the organization funding this project)? . B. Architecture (20 pts.) List the requirements you are focusing on. Explain the main architectural pattern used by your subsystem. Why was this pattern chosen? (Examples in Sommerville Section 6.3, Lecture Notes, etc.) Draw the high-level architecture and discuss the rationale for this architecture. Tie the choice of architecture to requirements, particularly non-functional ones. C. Module Design (25 pts.) Precisely describes each module in your design. As needed, each module should be further broken down into sub-modules. To assist with understanding, also draw your sub-modules (e.g., Fig 2-1 below). Each module, at whatever level, must be described as follows. If you are using interfaces provided by another team, please refer to the project name and their module. The purpose of the module: State the generic purpose of the module. Specify which part of the requirements document it addresses, if this is appropriate. (Appropriate items to address here include such topics as: What secret does this module hide? Does the module represent a specific data type or data format?) The provided interface: Define the provided interface by listing all its methods with descriptive names. The definition includes the names of the methods, their parameters, and their return types. Provide a short commentary describing each of the methods (i.e. what it does). The required interface: Define the required interface by listing all its modules/methods. Note that every one of the modules/methods listed should be described elsewhere in this document, either as part of the design which you are creating or else as an externally provided service. Constraints on the module: E.g., performance constraints, platform requirements, and so on. Only include this part if necessary. . Rainbow Fish: Your friends ask you to develop a website for their business during dinner at their new restaurant. The web site should include common advertising information like special events, hours, location, social media with reviews, and menu. At some point in the future, they would like to include an ability to make reservations, show daily specials, and take carryout orders on-line. The owners want to trade you free dinners for your development work. Functional Requirements: What user can see and interact with 1. As a customer I would like the background color to not distract me from the actual information 2. Transaction corrections, adjustments and cancellations 3. As a consumer I would like the information available to be correct, this includes hours, prices, menu items, and events. 4. As a customer I would like to see pictures of all the main dishes 5. As a customer I would like to see a calendar with all the special events and have the option to add the ones I like to my personal calendar. 6. As a manager/user I would like the ability to easily make changes to the website. 7. As a manager/user I want accessibility to view the algorithms of the website, this includes things like number of viewers and clicks. 8. As a customer I would like to have a live chat to answer my questions about the restaurant. 9. As a customer I would like to sign up for newsletters to receive emails about any deals or special events. Future Add ons 10. As a customer I would like the web application to accept my order and text/email confirmation. 11. As a customer I would like the website to be able to accept payment. 12. As a customer I would like the website to produce a receipt. 13. As a customer I would like to know that my personal information is safe and secure and wouldn't be jeopardized 14. As a manager I would like the website to develop weekly, monthly, and yearly reports about the sales. 15. As a customer I would like the website interface to function properly with a mobile web browser. Non-Functional Requirements: important, user doesn't interact with directly 1. Website should load within 5 seconds. This is important because the users will have a better experience with the website. For every second the site takes to load can decrease customer satisfaction. 2. The system should be capable of handling thousands of users without affecting its performance. This is necessary for efficiency and easy access. 3. Accommodate for future add ons, the system should be adaptable so it can handle future services easily. This is important to avoid future problems when making those changes. It's now time for you to design the system, based on the requirements you produced in the Requirements Activity. Choose 8-10 requirements. If your requirements were too far-ranging for this stage, you may modify them. List which requirements you will be using as the basis for this design. You (the group) are the software architect / technical lead for this project. You need to produce a design document containing the system architecture and detailed design for the system modules. Provide the necessarily diagrams and descriptions following the guidelines below and an example in the Appendix, Lecture notes and Sommerville Chapters 5 and 6. Deliverable: Your design diagrams and description in a single MS Word or PDF document _Design.doc Rubrics: a) Introduction (5 pts) b) Architecture (20 pts) c) Modules (25 pts) . 0 Your key task is to create a design document that contains the following deliverables: A. Introduction (10 pts) Project title Purpose of the design document What is this document about and who are the intended users of the document? What is the product you will be implementing? Who are the product's customers and users? Who created / initiated this project (i.e. who is the organization funding this project)? . B. Architecture (20 pts.) List the requirements you are focusing on. Explain the main architectural pattern used by your subsystem. Why was this pattern chosen? (Examples in Sommerville Section 6.3, Lecture Notes, etc.) Draw the high-level architecture and discuss the rationale for this architecture. Tie the choice of architecture to requirements, particularly non-functional ones. C. Module Design (25 pts.) Precisely describes each module in your design. As needed, each module should be further broken down into sub-modules. To assist with understanding, also draw your sub-modules (e.g., Fig 2-1 below). Each module, at whatever level, must be described as follows. If you are using interfaces provided by another team, please refer to the project name and their module. The purpose of the module: State the generic purpose of the module. Specify which part of the requirements document it addresses, if this is appropriate. (Appropriate items to address here include such topics as: What secret does this module hide? Does the module represent a specific data type or data format?) The provided interface: Define the provided interface by listing all its methods with descriptive names. The definition includes the names of the methods, their parameters, and their return types. Provide a short commentary describing each of the methods (i.e. what it does). The required interface: Define the required interface by listing all its modules/methods. Note that every one of the modules/methods listed should be described elsewhere in this document, either as part of the design which you are creating or else as an externally provided service. Constraints on the module: E.g., performance constraints, platform requirements, and so on. Only include this part if necessary