Assignment 4 Instructions

Instructions:

Menu exercise

In this assignment, you must create a menu for XYZ Company’s Budgeting System. The system is a stand-alone application that uses a Visual Basic front-end and a SQL Server database on the back-end. The screens have already been designed, but the menu system has not yet been developed. The following background describes how the system should work.

• Each budget consists of various scenarios (such as “Best Case,” “Worst Case,” “Most Likely,” etc.). The user can create as many scenarios as he desires, and it is up to him to manage the scenario (i.e., name it and assign its assumptions).
• Each scenario consists of 20 assumptions (such as anticipated revenues, employee attrition, employee salaries, benefits, and various other expenses).

Although you do not need to understand the entire functionality of the system, you do need to know the various screens and features that have been developed. Note that the application opens with a main screen that contains a dashboard describing the number of scenarios that have been created, who created them, and the date on which they were created and last modified. Below is a list of features that the system performs and the type of implementation (i.e., separate screen, dialog box, etc.) for each feature.

• Create a new scenario – A separate screen is used to create a scenario.
• Open an existing scenario – An “Open File” dialog box allows the user to select which scenario to open. When the user selects a scenario from the dialog box, a separate screen opens that displays the scenario with all of its assumptions in a grid.
• Delete a scenario – A small screen opens that has a list of all the scenarios on it. When the user selects a scenario for deletion, he is prompted “Do you really want to delete this scenario? This action is not reversible.” If he answers “yes,” the scenario is permanently removed from the system.
• Rename a scenario – A small screen opens that has a list of all the scenarios on it. When the user selects a scenario to rename, he is prompted to enter the new name.
• Make a scenario the “Current Scenario”—A small screen opens that allows the user to select a scenario and make it the active scenario. Note that some actions can only be performed on the “Current Scenario.”
• Create an assumption – A separate screen is used to create an assumption.
• Edit existing assumptions – A dialog box allows the user to select which assumption to edit. When the user selects an assumption from the dialog box, a separate screen opens that displays the assumption with all of its properties in a grid.
• Delete assumptions – A small screen opens that has a list of all the assumptions on it. When the user selects an assumption for deletion, he is prompted “Do you really want to delete this assumption? This action is not reversible.” If he answers “yes,” the assumption is permanently removed from the system and all scenarios to which it is assigned.
• Add assumptions to the current scenario – A screen opens that lists all of the assumptions for the current scenario on the left side of the screen and all of the available assumptions on the right side of the screen. To add an assumption to a scenario, the user clicks one of the assumptions on the right side of the screen and drags it into the current scenario’s list of assumptions on the left side of the screen.
• Remove assumptions from the current scenario – A screen opens that lists of the assumptions for the current scenario in a grid, and the user can select which assumption he desires to remove from the current scenario.
• Save Current Scenario – This functionality should not open a separate screen, but rather save the “Current Scenario,” which writes to the database the mapping of all of the assumptions that have been assigned to the scenario.
• Save Assumption – This functionality is only available on the screen in which the assumption is being edited.
• Exit Application – This exits the entire application.
• Enter base values – This opens a screen that allows the user to enter baseline numbers (i.e., how many employees are currently employed, current salaries for employees, current tax rates, year-to-date balances in various expense accounts, etc.). These baseline numbers are used in the calculations for assumption projections.
• Run – This feature runs all of the calculations associated with the combination of assumptions for the current scenario. For example, an assumption that projects 20% attrition will multiply this rate times the baseline number of employees to determine the projected amount of attrition for the scenario.
• Add Years to the current scenario – Scenarios are defaulted to contain three years’ worth of projected data. If a user wants to extend his projections to four or five years, he can add years to a scenario. The user is issued a prompt that asks him how many years to include in the total projection for the scenario. New calculations are not performed. The user must “Run” his calculations to populate the newly added years.
• Produce reports for scenarios – Reports are used by management to determine various projected expenses for the current scenario. The following reports are available to be displayed. Note that these reports are displayed on the screen AND they should be able to be printed to a file or to a printer.
• Compare Scenarios – A separate screen allows the user to select two or more scenarios to compare his assumptions. Another screen allows the user to select two or more scenarios to compare his profit/loss results.
• Administration of permissions – A separate screen is designed to allow administrative users to manage permissions of other users. This screen should only be visible to users who are designated as administrators of the system.
• Administration of Archives – A separate screen is designed to allow only administrative users to archive scenarios. The archiving functionality consists of several distinct features that are implemented on different screens:

• Projected expenses by Product (table format)
• Projected expenses by Region (table format)
• Projected expenses by Employee type (table format)
• Projected expenses for the whole company (table format)
• Projected expenses by Product (chart format)
• Projected expenses by Region (chart format)
• Projected expenses by Employee type (chart format)
• Projected expenses for the whole company (chart format)
• Projected revenues by Product (table format)
• Projected revenues by Region (table format)
• Projected revenues by Employee type (table format)
• Projected revenues for the whole company (table format)
• Projected revenues by Product (chart format)
• Projected revenues by Region (chart format)
• Projected revenues by Employee type (chart format)
• Projected revenues for the whole company (chart format)
• Projected Profit/Loss Statement by Product (table format)
• Projected Profit/Loss Statement by Region (table format)
• Projected Profit/Loss Statement for the whole company (table format)
• Projected Profit/Loss Statement by Product (chart format)
• Projected Profit/Loss Statement by Region (chart format)
• Projected Profit/Loss Statement for the whole company (chart format)
• Assumptions for the scenario

• One screen is used to create a new archive and assign scenarios to it.
• A different screen is used to select an existing archive and retrieve a scenario from it for viewing.
• Baseline numbers from old scenarios can be imported into a new scenario. Therefore, a separate screen is used to open an existing archive for importing such numbers into the current scenario.

Deliverables:

• In a Word document, in 300 words or more, describe how you would implement a menu for this system. For example, would you use the same menu on the dashboard and on all of the different screens or a different menu on each screen? Would you use pop-up menus? Would you make all options on every menu available to all users?
• In the same Word document, draw mock-ups of how each menu will appear. You may use a drawing tool (such as Paint), a programming language (such as Visual Basic, which allows you to easily create menus), or even a hand-drawn picture that you scan into a Word document. You do not have to reproduce how you envision the screen to look – only the menus that appear on the screen(s). You may or may not decide to put a menu on each screen, but on whichever screens you desire a menu, draw a mock-up of that menu for that screen.