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. . 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