Only point (3,4 and 5) Architecture Diagram (rough), Memo to the client, Requirements (CH 8) Using identified requirements from the project scenario assigned to your team, create an abstract/top-level architecture diagram to conceptually illustrate the program (e.g. remote sites, central servers, distributed servers, n-tiers).  Use a diagram software of your choice to create this. The purpose of this is to evaluate the needs of the system, conceptually illustrate to the client how the system will be outlaid. If your prompt indicates your system will be hosted in an existing data center, consider how users will access and interact with the system, or how the system will interact with other systems. Create up to a 2pg maximum write up, in the form of an email/memo to your [Client] justifying/explaining why this architecture has been chosen, and how it meets the requirements. This write up should also discuss any identified pros and cons with this approach. If there are identified requirements that could be considered ‘major’, feel free to discuss them in the write up.    The write up should include a table of identified requirements from the program (refer to CH 8 for requirement types, examples). Groups are encouraged to take creative license with identifying/determining the requirements. Think abstractly about what requirements the program/system should satisfy, even if they are not explicitly stated in the scenario. Consider Operational, Performance, Security, and Cultural & Political requirements. ** The identified requirements for the table are NOT required to factor/influence the other deliverables for this project** The architecture diagram and the requirements table do not count towards the 2pg maximum length of the memo, and should be included in the same document satisfying the deliverable. 2  Interface Design Prototyping and Evaluation (CH 9) Create interface design prototypes to comprehensively illustrate the project’s forms, functions, types of information displayed/captured, and flow. You may use any number or combination of interface diagram types from the book, or other types not yet discussed in the course to accomplish this objective. The type of diagram(s) utilized should be noted for clarity’s sake.   The project is anticipated to have a significant number of screens, forms, and reports. All of these should be represented in the User Interface designs.  Groups should be mindful of user interface design principles including, but not limited to, Layout, Content Awareness, Aesthetics, Usage Level, Consistency, and Minimization of user effort. Ensure that consideration is given to input mechanisms, outputs, and navigation principles. Groups may use more polished prototypes if they wish by using any number of available tools. However, keep in mind the purpose of abstract prototyping and the benefits they provide before skipping to more “finished” products. Using Trello, complete a heuristic evaluation for your interface design prototypes using the following template :https://trello.com/templates/design/heuristic-evaluation-tlVIJm0l (Links to an external site.) by adding the template to a new board in your workspace shared amongst your team. This should identify and catalogue UI/UX issues you’ve identified for this deliverable. Not all items may be applicable, and you may wish to add additional evaluation items. 3 Personas & Use Scenarios (CH 9) Create six fictional personas of the system, using the examples on pg 275 of the text for a loose reference. These personas should reflect the scenario’s identified user types. Personas do not have a specific length, but they should include sufficient information to act as an aggregate common characteristics of a particular user group. Personas should also act as a lens through which a system and its user interactions are viewed, as this can aid designers in conceptualizing how users may interact with the system, or their needs in doing so. You may find this article helpful in understanding the value personas can add to an interface design: https://blog.adobe.com/en/publish/2017/09/29/putting-personas-to-work-in-ux-design-what-they-are-and-why-theyre-important.html#gs.y8axq3 (Links to an external site.)  Write a use scenario for each of the personas (six total use scenarios). The use scenario should go through a commonly used path in the system. The structure chart and interface prototypes should facilitate the use scenarios. Your user stories should include the Who (persona), an objective/goal or what they want to achieve, and the reason for doing so.   Each user story should also include the steps or sequence of actions to accomplish that in the system. Pg 275/276 may be a helpful reference. You may find this article helpful, as it provides a deeper look at the purpose of user stories in the SDLC: https://www.atlassian.com/agile/project-management/user-stories (Links to an external site.) 4Program Design - Structure Charts (CH 10) Create a structure chart for the project. It is strongly advised to review CH10 for guidance. You may find that due to the limited scope of the project, and a lack of preceding documentation (DFDs, Requirements Definitions, etc) that this deliverable may spur changes in Deliverable 2, and vice versa. This is expected, due to the iterative nature of this project. A successful structure chart will demonstrate an understanding of modular design, and associated concepts. Coupling and Fan-In should be considered in the design and construction of your chart. The symbols listed in the textbook (pg 321) for structure chart design are optional but may help your group conceptualize the modular design. If groups choose to include them, they have that liberty. However it will not factor into my grading schema/evaluation on their own merit. Conceptually it may be helpful to recognize that the interface design prototyping in Deliverable 2 represents what the user(s) interacts with, whereas the structure chart and breaking down the system into modules represents the “under-the-hood” or code that facilitates the system functions and processes.  The ‘gas’ pedal in your car may have a simple interaction to the driver [user] “depress pedal, car moves forward. Push harder go forward quicker”, but causes a sequence of events for the car [system] involving computer calculations, valves opening, fuel injection, and other functions. It’s these underlying functions that we are trying to identify, structure, and break down into modules for the purpose of facilitating software development to achieve them. 5 Program Design - Program Specification (CH 10) Create a program specification for each module identified in the Structure Chart from Deliverable 4. Program specifications do not have a set syntax – feel free to use a style and template of your team’s choosing. It must at minimum include program information, events, inputs/outputs, and pseudocode. Refer to the definition of pseudocode on pg 337 of the text for guidance. Pseudocode should be sufficient to function as a blueprint on how to develop the code required for that module. It is an abstraction of code written in narrative English, with the purposes of eliminating ambiguity in what the actual code for the module should do. For the purposes of project submission, each module must have a program specification dedicated to it. All program specifications should be compiled into a single document, with each program specification clearly delineated. The guidance and loose principles on pseudocode at the following link may be helpful for your team in maintaining consistency across your program specifications: https://towardsdatascience.com/pseudocode-101-an-introduction-to-writing-good-pseudocode-1331cb855be7 (Links to an external site.)

Projects are initiated to solve business problems or create an opportunity.Discuss the relationship between the business environment and project scope.Provide examples of reasonable and irrational reasons for scope changes.