Background to the problem

Newtown Hospital Radio is a voluntary organisation, and a registered charity. They broadcast music shows, as well as some talk shows, to Newtown General Hospital twenty-four hours a day.

There are three groups of volunteers who work at the hospital radio: The support staff, the presenters, and the executives.

The support staff completes the more menial tasks that are, nonetheless, essential to maintaining the hospital radio. These tasks include visiting the wards to get requests from patients, keeping the studio clean and tidy, and keeping the record library in order. Also, technical support staff must keep all of the studio equipment in full working order. There are more specific support staff, too, such as the secretary and the treasurer, who complete all the more demanding jobs at the station.

The presenters are responsible for recording a new edition of their show every week onto MiniDisc. Each show is played several times each week, so that the presenters do not have to record too much material.

The executives are in charge of the radio station. The executives are made up of elected representatives from each of the groups of volunteers, as well as a chairperson. They are responsible for all of the major decisions about the running of the radio station.

I have chosen to base my project on the Newtown Hospital Radio as I have worked with them in the past on many different projects, and because they are desperately in need of a new system to replace the current one.

Identification of the problem

Currently, an index of the record library is kept using a system of index cards. One set of cards is arranged in alphabetical order of song title, and one set is arranged in alphabetical order of artist. However, the number of items in the record library is beginning to grow to such a level that an index card system is rather impractical. Also, if a request for a specific song is made, but neither the full title or artist’s name is known, then the song cannot be found.

Member’s details are also currently kept in an index card system. There are also several problems with this system. For example, if a member of Support Staff needs to be contacted, then the secretary must look though the cards (which are arranged in alphabetical order of name) until a member of Support Staff is found. Also, if all executives are to be contacted, then the entire index card system must be browsed to find those members who are on the executive committee. As the number of members grows, this is getting to be rather time-consuming. Also, it is inevitable that index cards go missing, as people remove them to copy out an address or a phone number, and then forget to replace them. This makes the whole system totally inaccurate.

Twenty-four hour broadcasting is a new venture for Newtown Hospital Radio, and has required an increase in the number of presenters. Previously, presenters were allowed to record their shows in the studio whenever they had a spare hour. But, as more presenters are recruited, several have arrived to record their show at the same time. This has led to a number of disagreements within the organisation, and, ultimately, several presenters have moved to other hospital radio stations. Currently, no system is in place to deal with this problem.

The data that I will use in my systems once they have been constructed can be easily researched from the current index card system.

Identification of prospective users

There will be many different users of the new system, since all support staff and presenters will need to be able to find records using the system, and all presenters will need to be able to book time in the studio to record their shows. Also, executives may need to access the member database to communicate with volunteers. Therefore, there will be many different users with varying degrees of computer experience. Therefore, the system will have to be very user friendly, since some users have never have tried to operate a computer before, and few have the time to be trained how to use it. Operation of the system must therefore be clear, so that most people will be able to operate it without training.

Identification of user needs

The system must be able to do the following:

• Store and allow update and deletion of information about each song in the record library
• Track ID (So that it can be found in record library). Track ID is made up of a four digit number (MiniDisc number), followed by a dash, and then a two digit number (Track Number)
• Track Title
• Artist
• Style of music (Jazz, pop etc.)
• Length of track
• Find a track or tracks by searching on any of the above criteria. The results of this search will be displayed on the screen for immediate reference. Hard copies would not be beneficial since the majority of presenters plan their shows from the studio.
• Allow the user to browse through the songs available and view details of any chosen song.
• Store and allow update and deletion of information about each member
• Name
• Address
• Telephone Number
• Status (Support / Presenter / Executive Support / Executive Presenter)
• Find a member or members by searching on any of the above criteria. Again, the results of this search will be displayed onscreen.
• Allow the user to browse through a database of members view the details of any chosen member.
• Allow a presenter (and only a presenter) to book an hour when they can use the studio. Although not originally suggested, after discussion with current members, a system whereby a data sheet of bookings could be printed has now been suggested. Therefore, my system will also allow the printing of a list of bookings made by members. Also, a list of tracks that each presenter wants to use during their booked time will be stored, and printed on the booking data sheet.
• Print members’ details ordered by status should be available, as this could serve as a useful telephone directory.
• Print a list of all of the tracks in the music database should also be made available, so that the few presenters who choose to plan some of their shows at home are catered for.

I will complete this task by using a Microsoft Access Database, fronted by a Visual Basic program. This way, I will be able to customise the look and feel of the way in which the database is accessed, and I will be able to do much of the complicated searching and querying “Behind the scenes”, thus making the system very easy to operate.

There are relatively constraints placed upon the system, as Newtown Hospital Radio is equipped with a computer and Microsoft Office. Since the database is never, at least in the foreseeable future, going to reach millions of data items stored, then processing power is not going to cause too much of a problem, as the system is fairly up-to-date and has a powerful processor. Also, the 20Gb hard disk should be ample for this system. All of the hardware needed to run my system is clearly available.

A backup is already made of the system on a weekly basis, as the computer is currently used by the secretary for typing letters. Backups are made on Zip Discs, which are then stored at another location (the secretary’s house). Using specialist software, the technical manager is able to remotely take control of the computer from home, so that any problems with the system can easily be fixed (the technical manager is computer literate).

Realistic appraisal of the feasibility of potential solutions

There would be many ways of approaching this project, using software and programming languages as described below:

• Pascal: A program could be written in Pascal to handle the above data.
• Access: Microsoft Access could have been used on its own, without any fronting being completed by a Visual Basic program.
• Excel: Microsoft Excel could be used to store the data.
• Basic: A program could be written in Basic to handle the data
• Manual: A manual system, with a few modifications and additions to the current manual system, could be used to store the data.

Justification of chosen solution

I chose not to complete the project using the above solutions for these reasons:

• I did not want to complete the system in Pascal or Delphi, since a user interface with which the majority of people would be familiar (i.e. a Windows-style interface) would be very difficult to create using this programming language.
• I did not want to complete the project using Microsoft Access alone, as this would have made it very difficult to present the user with an interface that is easy to understand. It would, realistically, have meant that the user would have to be familiar with writing Microsoft Access queries. Although, theoretically, a user can be protected from this by using Microsoft Access’s own programming language, this is extremely difficult, and would probably have resulted in a very high maintenance system.
• The project could not practically be completed in Microsoft Excel. Again, attempting to build a system of this scale in Microsoft Excel would make it very difficult to present an easy-to-use, intuitive user interface, since many advanced options, which the user does not need to use, would be ever present.
• Basic has the same inherent problems as Pascal: It is very difficult to build a windows-style environment using this language.
• A manual system would not be able to fulfil all of the criteria set out for the new system, since it would be impossible to search a manual system. Furthermore, a computerised system can have regular backups made with greater ease, and security of information can be improved. Also, presentation of printed material is far better than presentation of hand-written material, and can reduce error (e.g. when information about a record is copied from an index card, it is very easy to incorrectly copy the record number, which ultimately results in the user being unable to find the record.)

I have chosen to complete my project in Visual Basic and Microsoft Access as I familiar with these, and a suitable system can be built using them. I will also be able to decide exactly what I want to show to the user, and so will be able to hide any unnecessary options from the user, whilst still maintaining a windows style.

There are, however, some disadvantages of my system. For example, those with absolutely no computer experience will need training in its operation. However, since the computer software is already in place, I do not think that the new system will be any more expensive than the current one.

Data source(s) and destination(s), logical DfDs, and an E-R model

For this section, it seems logical to split the project into three separate sections: Record database, Member database, and Booking system.

In the record database, the data that comes from the cover of the MiniDisc is entered into the manual database, for retrieval at a later date by a presenter or member of support staff:

The new system will be much the same, but only one Record Details file will be kept. Also, searches and validation will take place:

Currently, the member database is very similar to the record database in terms of data flow:

However, the new system will have a slightly more complicated method of data flow, as a booking system is to be added.

The entity relationships for this system will be as follows:

Thus, one presenter could, in theory, have more than one booking per week.

The data flow in the proposed system will be as follows:

Objectives of the project

The objectives of this project are to fulfil the users’ needs by producing a system that can:

• Store and allow update and deletion of information about each song in the record library
• Track ID (So that it can be found in record library). Track ID is made up of a four digit number (MiniDisc number), followed by a dash, and then a two digit number (Track Number)
• Track Title
• Artist
• Style of music (Jazz, pop etc.)
• Length of track
• Find a track or tracks by searching on any of the above criteria. The results of this search will be displayed on the screen for immediate reference. Hard copies would not be beneficial since the majority of presenters plan their shows from the studio.
• Allow the user to browse through the songs available and view details of any chosen song.
• Store and allow update and deletion of information about each member
• Name
• Address
• Telephone Number
• Status (Support / Presenter / Executive Support / Executive Presenter)
• Find a member or members by searching on any of the above criteria. Again, the results of this search will be displayed onscreen.
• Allow the user to browse through a database of members view the details of any chosen member.
• Allow a presenter (and only a presenter) to book an hour when they can use the studio. Although not originally suggested, after discussion with current members, a system whereby a data sheet of bookings could be printed has now been suggested. Therefore, my system will also allow the printing of a list of bookings made by members. Also, a list of tracks that each presenter wants to use during their booked time will be stored, and printed on the booking data sheet.
• Print members’ details ordered by status should be available, as this could serve as a useful telephone directory.
• Print a list of all of the tracks in the music database should also be made available, so that the few presenters who choose to plan some of their shows at home are catered for.

» Next Section: Design