Submission 5 A functional description section 2 PAGES Should describe briefly the services which the system provides Users

rs should be able to read the document along with the introductory manual and decide if the system is suitable for them Quick reference card section 2 PAGES Should describe the system facilities and their usage Including a list of error messages and possible causes Also a description of how to recover from the detected errors Project review section 3 PAGES Changes to plan Risks encountered which had not been expected by the team Changes to requirements Changes to design as a result of prototyping Evaluation of the system your team developed

Functional Description The company in question, Winter Valley Ski Resort, is a Switzerland-based Ski holiday Booking Company owned and managed by Michael Davis. The service they offer is tailor made ski holidays aimed at any age and kind of person. When Michael was asked about the target market for his business, he stated it was everyone. Currently their system is entirely paper based. This system is leading to a significant amount of problems such as information and bookings being lost, but they are looking to change this to a computer based booking system to benefit them in many ways. A new system would allow them to save money, manage bookings more efficiently and produce professional reports to management to show statistical information. The current system they operate is based in Switzerland with a booking office in Belfast. There are four members of staff, and Michael the manager makes a total of five. Our research and conversations with Michael drew our attention to three main competitors who are more technologically advanced and therefore reap the benefits of that. At present they record all information on paper, and this leads to information being lost and ultimately unhappy customers. It is also a very time-consuming method of running a company. With the new system, they require a computerised method of entering, storing and manipulating data. It would minimise mistakes and lead to a more organised and orderly working environment. Michael would like to store data on such things as the size of booking, number of people/infants, flight information and data on the types of accommodation available to customers. The company would like the new system to be created and implemented by the end of April. They hope to be able to increase the customer base by 50% as well as the businesses financial status by 30%-40% Product Functions At present many functions are carried out with the paper based method, although they are not completed efficiently or effectively. The new system should be able to complete all these tasks easily, and carry out more processes and functions that were before not available. Michael would like Winter Valley Ski Resort to be able to assist customers with numerous different functions, and these functions will be reflected in the new system. The company would like the system to be able to: Accept bookings and store all the required, important information that is needed. Book the customer ski lessons from an outsourced Ski Instructor. Book accommodation and allow a range of hotels to be chosen from. Produce professional and accurate bills to provide to customers as proof of bill total. Create regular, informative reports to provide to management.

Step-by-step Login At Login, the first screen the user is presented with, they enter both their username and password, which will have been previously set-up for them by management. Now depending on what user is entering the system they will either be taken to the Staff or Management section of the system. This split has been made for both practicality and security reasons. Management Database Once logged into the Management database, the user is presented with three menus Staff, Reports and Contacts. Staff This menus soul purpose is to deal with all things staff related. The system has been made so that it is flexible enough to change with frequent change in staff data. In the menu it gives you the option of creating, and amending the Staff Rota as well as creating or amending any staff working for the company. It is important that this stays as flexible to change as the company. Reports This menu has been created to simplify the report creating process. You are given the option of creating a Historical, Cash Flow or Monthly report. This is placed in the management part of the database, as management will only use it. Once any three of these options are selected the system automatically processes appropriate information and generates and presents the relevant information available to save and print. Contacts The Contacts menu is vital as it is important that the business remains in contact and up to date with the resorts, airlines, and banks they are corresponding with. This is to ensure they are getting the best deals for themselves and therefore their customers, and also to make certain they are receiving and paying all trade. Staff Database In the majority the Staff part of the system is likely to be used the most. Once entered into Staff two different Menus appear that allows you to make a booking, track a booking, search for holidays, cancel a booking, add customer, and search for a customer. Booking Before an actual booking takes place the customers details are taken and stored within the customer part of the staff database. After this has been done the user can then move on to make a booking for the customer. It is also possible to locate a previous booking, which is done by the track a booking option. Simply entering the booking reference number, which is supplied to the customer after confirming the booking, does this. This allows for flexibility within the system as the customer can decide on the accommodation at one meeting and then come back at a later date and decide what flight to take. Customer As previously stated, all customer details are kept for both report and practical reasons. As is required by the Data Protection Act 1998 however, all unnecessary information kept must be erased. This may be a previous customer who no longer book with the company. New customers are given a unique number, which can be used to identify them within the system. And when searched the user can view previous bookings made by the customer. An option to amend customer details is also available. Quick reference card section 2 PAGES

Should describe the system facilities and their usage Including a list of error messages and possible causes Also a description of how to recover from the detected errors

Project Review

Changes to plan Our team chose a democratic decentralised structure. We unanimously settled on this structure as it meant that all team members would be equal and no barriers would be created. Therefore, this also meant that problem solving and decision-making would be made by the team. A further characteristic that drew us to the democratic decentralised structure was that no individual role was defined and so team members were able to be flexible and change their roles once the task had been completed. This suited our team as all members are widely skilled therefore are able to contribute to all the tasks in hand to complete this project. When put into practice, very little change was made from our previous project plan. We remained as a democratic decentralized group and this allowed for every member to voice their opinion, and work on different parts of the project each week. This structure also allowed for a friendly and trusting atmosphere to emerge within the group. Due to the flexibility of this structure, when a member of the team fell ill towards the start of the project unable to contribute, other members of the team were able to step in and work effectively to help the ill team member, by completing some of their work. This unavoidable circumstance did well to test the effectiveness of the structure we chose. Each week following our client meeting, in which we would all attend, our group would discuss which part of the weekly documentation we would complete. Some team members would choose to work together on each bit, and some would work individually. This worked well as every team member could pick a section they felt most comfortable in, and numerous members working together would tackle the more challenging sections. Emails, and texts were used to correspond with other team members. Before the assignment was submitted the group would meet again to bring everything together to proofread. This was an unchanging routine as we felt it worked effectively. Risks encountered To avoid any risks being fatal or very damaging; at the start of our project we created a risk analysis. A risk analysis analyses possible risks that could occur during the project, and classes them by probability of the risk arising, and the effect it would have on the business. For example, when a member of the team is ill there is a high risk of this happening but the effects are only bad. To each of the predictions we will also provide a solution to avoid the risk being to damaging. A risk not encountered by the team was availability of resources during the Easter break. As all our team does not live in Belfast, and due to the expense of the needed software, during the Easter break team members did not have access to the needed software and this meant time being spent back in Belfast specifically for the project.

Changes to Requirements

Our team had to be flexible and just roll with changes; these changes are inevitable in project-life, so it had to be dealt with. However, to be able to construct something, requirements should be reasonably stable, at least long enough to build and test stuff. This stability however, can be forced by not allowing changes to the requirements; they are unmoving. Requirements in a project will have alternating periods of change and stopping. It's the role of the whole team to properly manage this process. There are several reasons why requirements change: Project team interpreted requirements different than intended by client . Fortunately during our project this did not happen as we regularly met up with our client to get to know him both personally and professionally. By doing this we allowed ourselves to get to know his goals for the business and started in doing the project through his eyes. We even waited until we had met our client before we wrote our initial requirements document. "Forgotten" requirements surface. During the project intake and the requirements determination the scope is determined and the initial requirements are written down. In this process you can forget one or two requirements that appear during the phase of feedback. However, this was also a possible reason we managed to dodge due to our well-developed project plan and minutes. By having a plan that we would try our best to stick to it made it almost impossible to forget important details for the system requirements. External changes in the project environment. Things happened outside the project that can affect the project directly. A reorganization, a new policy for booking customers, a new law, etc. The fluctuation in the surroundings can change requirements. The longer a project runs, the more vulnerable the project is to this type of changes. We were lucky that no such changes occurred to our clients business. The only change that would possibly fall under a requirements change was the changing of the logo, from a blue logo to a reddish logo. This did momentarily become a nuisance, however, our group pulled through and managed to get the reddish logo to fit in with the previous systems colour and design. Changes to design as a result of prototyping Changes here were minimal, and barely noticeable. Evaluation of the system your team developed In conclusion, we feel the system we have developed for Winter Ski Valley Resort has been a success. The problems Michael had been experiencing previously have been resolved. The efficiency and effectiveness of the system has been improved, along with its design and ease-of-use.