Develop a Software Design document that identifies all the necessary requirements for the system mentioned in the mid term project. This document must strictly follow the IEEE template for software design uploaded on canvas. However, there may be sections in the template that may not apply to the project, these sections can be eliminated.

1. Introduction:

Instructions: Provide identifying information for the existing and/or proposed automatedsystem or situation for which the SDD applies (e.g., the full names and acronyms for thedevelopment project, the existing system or situation, and the proposed system orsituation, as applicable), and expected evolution of the document. Also describe anysecurity or privacy considerations associated with use of this document.

1.1 The purpose of the system Design Document:Instructions: Provide the purpose of the System Design Document. This document should be tailored to fit a particular projects needs.

1.2 Design Consideration: Instructions: Describe issues which need to be addressed or resolved before attemptingto devise a complete design solution.

1.3 Goals and Guidelines: Instructions: Describe any goals, guidelines, principles, or priorities which dominate orembody the design of the system and its software. Examples of such goals might be: an emphasis on speed versus memory use; or working, looking, or feeling like an existing product. Guidelines include coding guidelines and conventions. For each such goal orguideline, describe the reason for its desirability unless it is implicitly obvious. Describeany design policies and/or tactics that do not have sweeping architectural implications(meaning they would not significantly affect the overall organization of the system andits high-level structures), but which nonetheless affect the details of the interface and/orimplementation of various aspects of the system (e.g., choice of which specific productto use).

1.4 Development Methods and contigencies: Instructions: Briefly describe the method or approach used for the system and softwaredesign (e.g., structured, object-oriented, prototyping, J2EE, UML, XML, etc.). If one ormore formal/ published methods were adopted or adapted, then include a reference to amore detailed description of these methods. If several methods were seriouslyconsidered, then each such method should be mentioned, along with a brief explanation of why all or part of it was used or not used. Describe any contingencies that might arisein the design of the system and software that may change the development direction.Possibilities include lack of interface agreements with outside agencies or unstablearchitectures at the time the SDD is prepared. Address any possible workarounds oralternative plans.

1.5 Architectural Strategies:

Instructions: Describe any design decisions and/or strategies that affect the overallorganization of the system and its higher-level structures. These strategies shouldprovide insight into the key abstractions and mechanisms used in the systemarchitecture. Describe the reasoning employed for each decision and/or strategy(possibly referring to previously stated design goals and principles) and how any designgoals or priorities were balanced or traded-off. Describe compliance with CMS Enterprise Architecture (EA) and standards. Specificallyidentify any deviations that were made from the CMS EA and standards, and providerationale to support the deviation(s). When describing a design decision, discuss anyother significant alternatives that were considered, and the reasons for rejecting them(as well as the reasons for accepting the alternative finally chosen). Sometimes it maybe most effective to employ the pattern format for describing a strategy. Examples of design decisions might concern (but are not limited to) things like thefollowing: a) Use of a particular type of product (programming language, database, library,

commercial off-the-shelf (COTS) product, etc.)b) Reuse of existing software components to implement various parts/features ofthe systemc) Future plans for extending or enhancing the softwared) User interface paradigms (or system input and output models)e) Hardware and/or software interface paradigmsf) Error detection and recoveryg) Memory management policiesh) External databases and/or data storage management and persistencei) Distributed data or control over a networkj) Generalized approaches to controlk) Concurrency and synchronizationl) Communication mechanismsm) Management of other resources.

1.6 Performance Engineering: A contributing factor to System Design will be Performance Requirements. Performance Requirements are the defined scalability or responsiveness expectationsof specific workloads that process on a system. Instructions: (a) Using the Performance Requirements defined in the Requirements Document,provide a detailed explanation that describes how the Performance Requirements wereincorporated into the systems design. Please refer to Sections 2.0 of the CMSPerformance Test Plan and Results Template for guidance on defining PerformanceRequirements. (b) Start preparing Production Load Model(s) in preparation for Performance testing.Please refer to Sections 2.1.1 of the CMS Performance Test Plan and Results Templatefor guidance on Load Model construction.

1.7 Hardware Architectural: Instructions: Describe the overall system hardware and organization, indicating whetherthe processing system is distributed or centralized. Identify the type, number, andlocation of all hardware components including the presentation, application, and dataservers and any peripheral devices (e.g., load balancers, SSL accelerator, switches,firewalls, with a brief description of each item and diagrams showing the connectivitybetween the components along with required firewalls, ports, and network bands utilized(e.g., management band). Include resource estimates for processor capacity, memory,on-line storage, and auxiliary storage.