Renaissance Choir Finance Management System
Renaissance Choir Finance Management System
Introduction
I will be making a system for the accounts of Renaissance Choir. Renaissance Choir are based in Emsworth and have 29 members. They sing at many events throughout the year and sometimes in Chichester Cathedral. They meet weekly.
Statement of Problem
Renaissance Choir require a system to manage their finances. It must be flexible and easy to use, so that anyone could come along and use it, without previous knowledge.
Schedule of Activities
Section
Weeks
Specification
.5
Implementation
3
Testing
.5
Evaluation
User Documentation
Total
8
Background
The current system is based on two books containing input and output for the choir. All entries are written into the book by hand, and the books have to be carried to meetings when necessary and this is not very convenient, and rather slow. A computerised system would be more efficient. The system needs to deal with petty cash, as a constant amount is usually kept as a float or for occasions where cash is required and not a cheque or other method of payment.
Overview
As the system needs to contain columns of data, a spreadsheet would be most appropriate. I would use Excel, as I am well acquainted with it and it has many useful features that I can use to my advantage. My system would be composed of several sheets- a main sheet with buttons to move between sheets, then other sheets for data entry, listing the entries and making graphs and pivot table reports. Each sheet would have a button to link back to the main menu, and to other relevant sheets. For instance the data entry screen ...
This is a preview of the whole essay
Overview
As the system needs to contain columns of data, a spreadsheet would be most appropriate. I would use Excel, as I am well acquainted with it and it has many useful features that I can use to my advantage. My system would be composed of several sheets- a main sheet with buttons to move between sheets, then other sheets for data entry, listing the entries and making graphs and pivot table reports. Each sheet would have a button to link back to the main menu, and to other relevant sheets. For instance the data entry screen would have a button to submit the data into the spreadsheet, which would activate a macro and move the data. It would also have a button to move to the data-listing screen, which would have a button to link back. The graph page would have a button that would create a graph, and another to clear it. The exit button on the main screen may also clear the graph as well as exiting.
Interview and Research Summary
I gave a questionnaire to my end user, who filled it in. This has given me much background and other useful information, that can be used to help produce the system.
Volume of Data
The system will be updated on a weekly basis, so it must be relatively easy to add, delete and change records, as it will be used so frequently. However, cheques need to be paid in at random intervals, and the system will need to recalculate totals and other formulae after each of these events. It must also be able to cope with petty cash, which can fluctuate.
Problems with the Current System
Problems with the current system are its inability to transfer data easily between the two books and the balance sheet, the fact that it is slow and rather inefficient, due to having two heavy books to carry around.
Hardware Full Potential
To get good performance from the system, the requirements would be:
200 MHz processor speed
6 MB Ram
6 Bit colour graphics or better
Software Full Potential
The features of Excel that I will use to create the system are: macros, buttons and controls, formulae, charts, pivot table reports, visual basic, linked workbooks and
Input and Output
The user will enter data every week. The volume of data entered will depend upon how many events were held in that month, as each event will probably have inputs to the system in income and expenditure. At the end of each month and at the end of the year, the data will be summarised and the summary probably printed. Also, the system will process the lists of data to produce sub-totals and totals over different time spans.
User Skill Level
My end user is pretty skilled with computers, as she uses them in her work frequently. Therefore the system will not have to explain basic computer functions or other very basic ideas in the user guide, and the technical guide can be pretty complicated.
Software Use
I will produce the system, but on the main page I will hide the gridlines. I may do this on other pages as well, so that unnecessary gridlines are not shown- if I want gridlines to be shown, then borders can be put around required cells where tables are required. Also, anything that shouldn't be altered (e.g. integral system parts) will be protected to prevent alteration. There will be macros to do things like moving between sheets and adding records.
Objectives to Perform
My end user wants the system to be able to:
* Hold both income and expenditure in one place
* Cope with petty cash that is used for floats at events and other purposes
* Be able to transfer data between sections easily
* Produce graphs and charts of the data
* Produce summaries of the data
Performance Indicators
* Must be able to open relatively quickly, even on lower spec machines
* Must be able to contain a large volume of data while still retaining a file size below 100 kilobytes
* It must be relatively easy and quick to enter data or perform other operations
* It must be relatively difficult to make mistakes while entering data (using drop-down lists, buttons, macros etc)
* It must be easy to get to specific sections
* It must be foolproof- e.g. impossible to alter critical system aspects
* It must be possible to alter the structure of the database when necessary
*
*
*
*
John Morgan
