The requirements for the hotel booking system were specified by three distinct subgroups of the hotel. These groups were the front desk, accounting, and room service. Because of our demand of security, the supplier group decided to add a management section to handle management only duties.

The front desk staff performs a variety of jobs including taking reservations and assigning a confirmation number, checking room availability, check-in, check-out and preparing the invoice, and general inquiries. These requirements were handled very well in the prototype. All the information that we specified was stored on each guest. Each room record also contained the specified information. After specifying guest and room information, the system would assign a room to that reservation or display a message stating no rooms of that type are currently available. All reservations could be viewed in the reservations view box at the bottom of the front desk screen. This will be very helpful for our staff as they can be prepared for incoming guests, and also to see who is currently staying at the hotel.

The accounting section of the system seems to be extremely well done. The final system matches our initial requirements almost exactly. The information that we wanted the system to keep track of included the room rate (single, double or deluxe), the payment method (credit card, cash or cheque), the cancellation fee, miscellaneous charges such as room service, phone bill and movie rentals, and finally, we requested that the system provide accounting reports. Each of these items was handled very well and the resulting interface was well laid out and easy to use. In hindsight, and as a future addition to the system, it would have been nice to have a more varied selection of reports. A commercial report creation program could be used to make a wide variety of user-definable reports available to management, which would help to increase productivity and efficiency, cut costs and fine tune the daily operations of the hotel.

The room service section also seems to be well done. We requested that the system keep track of wake up calls, and food orders. For each of these, we wanted the ability to track when the order was made, when it was to be delivered, what time it was actually delivered and who delivered it. For food orders, we also needed to track what was ordered, the total cost of the order, and any special instructions about the food.

The system, however, seemed to strike out in 2 of these areas. Firstly, it doesn't seem possible to record the actual time of delivery of an order. This isn't a big issue however - looking back it doesn't seem like this would have worked anyway. The intent was to track the performance of employees, but, if an employee delivered an item late, why would he want that known? He/she could just enter an earlier time.

The second issue is of more importance. It concerns food orders and the connection with the hotel restaurant. As it is currently set up, the system must keep track of the entire restaurant menu - a formidable task. Originally, we didn't really specify how this was to be handled. Thinking back, it might be best to have had a menu placed in each room, with each possible food item numbered. These numbers could then be used in the system to track the orders, simplifying it greatly.

We also specified that there should be some sort of security measures, such as passwords, used so the reservation system is only accessed by approved hotel personnel. The security for the system is set up really well as each employee of the hotel is assigned a security level. Each level gives access to one or more sections, i.e. level 0 gives an employee access only to front desk functions. An employee with management level of security has access to all sections. This security feature was implemented with a log on/off in which the employee had to enter his ID and password. An employee could change his own password once he had logged on, or the manager could change the password if the employee had forgotten it. The management section also included the ability to change the tax rate, add or delete employees, and add or delete items to the room service list.

Overall we think that the project satisfied the majority of our original requirements. It represents the system that we specified and they also added some enhancements.

In addition, the following items have been added:

• Ability to add new room types
• Alarm system for room service personnel triggered when a room service request is due for completion.
• Ability to list different types of food orders for a sepecific room service request
• Ability to have a group booking
• The look of the invoice seemed to be layed out more like paper invoice compared to the previous entry box invoice.
• When changing a password the user must confirm the new password
• Quarterly and date to date search criteria are now on different windows
• Employee listing screen is very different it now shows a complete listing of employees instead of individual listings

The were a few deficiencies with the interface itself. Specifically the pulldown for the quarterly reports would be too large since these reports are stored for a minimum of 6 years. Also the overall design was a little cluttered.

We had mentioned in our specifications that the customer be able to book specific rooms (possibly blocks of rooms). This was not implemented in the prototype. This is a problem for our more frequent guests. Also, people cannot book different types of r ooms in the same check-in. This is a small problem for us because having to manually book different rooms is a hassle for our staff.

Exact description of room services purchased is not available. This is a problem during check out. Customers often want to examine their individual charges to make sure there are no errors. This cannot be accomplished with the current system unless we manually show them on the screen. This is a nuisance for both the customer and the Front Desk Staff.

There is no keeping track of what employee completes what transaction. This was clearly specified in our original specification documentation. While miniscule, we at Hotel451 feel that employee auditing is an important feature of our future system. T his prevents the abuse of the system by employees and further adds to strengthen Management/Customer relations.

Although not specified, it certainly have been nice to have the online help feature at least partially implemented. This would have given us at Hotel451 a chance to become more familiar with some of the advanced features of the prototype without extens ive instruction. This would also avoid having to read the user manual cover to cover.

All in all these minor discrepancies do not take away from the overall functionality of the system. It is our opinion at the Hotel451 that our supplier did an exceptional job of supplying an implementation suitable to our needs. We would not hesitate f or a second to contract them for any future projects.

For the most part specification was really redundant. Having a customer who was not very familiar with the desired product did not help in the designing of the system. The customer should have had more time to understand better what was needed for th e project.

Understandably, the designing process was good in that it got us all thinking about what a customer in this situation would want and it helped the suppliers to define better what we as customers wanted as a final product. The suppliers did a fine job in assessing our informal

specifications even though they may not have been very specific and particularly precise. The final end product was very well done and as such, the design process was definitely of help. It would have been preferable had there been more time for cust omers to truly understand the requirements of the product so as to give the suppliers less work in the area of design that many of them ended doing.

Looking further at the design process for the suppliers, with their test plans and other specs, including DFD’s and data dictionaries, it would have been good for the customer group to have been given an opportunity to look at the final design of the s ystem before a formal presentation of the material. This would have made for a more interactive session where the customers would have known the system better and would have had the opportunity to ask more appropriate questions during the presentation. After all, the customers haven't actually touched this project for over a month in time and may not remember as many of the points of importance that the system should or shouldn't have.

Though very difficult to implement in a classroom setting, it would definitely have been better had the customers and the suppliers had more time to spend together going over the actual implementation of the system being designed and actually being the re for meetings to evaluate progress on the project and to help determine whether or not the work being done was what was envisioned by the customer. As stated above, this is very difficult to do in a classroom setting, but it would have produced a much more cooperative final product than the actual system designed.

Some of the design process was very repetitive and seemed rather nonessential, like the DFD’s and the data dictionary which groups had to do. The functional specifications were helpful to an extent, helping to define what the system needed to be able to accomplish, but once again there comes a point where redundancy between different parts in the design process becomes more of a waste of time than of any great helpfulness to the actual implementation of the system.

While the design assignment proved to be a valuable teaching aid in this course, several changes could make it even more effective in conveying the importance of the various aspects of the design process (from the customer's perspective).

Throughout the course, the customer groups have been plagued from a lack of communication with their respective supplier groups -- thus only the most urgent clarifications to the design specifications get attention, while the smaller details are left unattended (giving the supplier group, in effect, a carte blanche to fill in the details -- while this extra freedom may also be seen as an advantage, if the results are not desirable to the customer, although the product matches the given specifications, then problems ie misunderstandings between the supplier and customer result).

The crux of the problem lies with the time allotted to complete the projects -- the design specification phase of the project was rushed (at the start of the course), and the implementation phase was a little rushed as deadlines loomed over the supplier group (who did a good job in supplying us with a working prototype). Thus, an environment that was not conducive for customer - supplier communication was established -- we (the customer group) were not an integral part at every step of our supplier's design process, and it was difficult at best to coordinate customer - supplier joint group meetings to further refine the specifications.

While it is understandable, given the total time allotted to the course, that time constraints will occur no matter how the time is divided; it would prove valuable if the customer's role in the design process were emphasised a little more. Unfortunately, while the supplier's role in the software development process is adequately emphasised in the design assignment, the customer's role (which starts off strong) fades into the background until the end of the course.

The documents produced by the supplier group were intended to provide a large amount of information to the customer. These documents were rather lengthy and it is somewhat apparent that quantity rather than quality was the goal. These documents are necessary to the design process though. More discussion on the format of these documents in lectures would have been more helpful. The idea of not having to follow a certain format allowed the group to be more expressive and free flowing but although the number of pages required for the document should have only been a guideline, it seemed like there was an emphasis on this. The content of the documents should have been focused upon much more.

The discussions in lecture should have played a larger role in the actual implementation of the system. The project and the "real" world still seem very distant. No policies were necessarily implemented in the groups, no particular business standard had to be met. Behavioural aspects of group work should have been emplasized, which was the case in some groups, but for the most part, the real sense of being part of a team was not really felt.