7. Third Development Iteration
8.3 Features Developed
The analysis denoted a list of requirements derived from the proposed features of the system gathered in the background research. For each feature a solution was devised in order to fulfil the clients requirements. This section of the report discusses whether or not
each of the features has met the client’s requirements. Discussion will take place on the criticism of each of the features and potential future development.
One of the main features of the system was to incorporate an administrative interface that adapts to the user access – the ability to display system components that are only relevant to the given user. This feature was successfully implemented. Each user accessing the prototype system tested the login. The chef, supplier and manager were able to login to the system and as a result were able to access the components of the system that were relative to them.
The manager’s interface was given an additional feature, not promised in the requirements. As usability was noted as an important factor in the earlier stages of the project, a configuration tab was provided to increase usability. The tab allowed for system to be customised when required via the use of uploading a logo or favicon and changing the name of the restaurant via a form. Although, the customisation provided was fairly limited, compared to some CMS available. A template system could have been provided to allow for further customisation in the system. Within the scope of the project and projected
requirements, this feature did not seem appropriate. The system produced was a prototype; this meant that the fundamental components of the system such as reservations took priority over additional features such as a template system. If a final build of the system was to be developed, additional features such as the template system could be implemented.
The user accounts requirement was fulfilled via the user tab. The tab enables the manager to add, edit, remove and assign roles to users. What it didn’t account for was a function to add new roles to the system, i.e. a waiter or waitress. Although in the scope of requirements set at the beginning of the project, all the roles observed in the clients business have been covered. It is also quite likely that different businesses may contain employees that perform single or multiple roles. The system does account for; multiple roles may be selected via the use of checkboxes. This feature was implemented for future
development purposes, i.e. if new roles were to be added.
The pages tab enables the manager to add, edit and remove pages from the website. Implementation of the feature was success. Although, access was restricted to ‘Food’, ‘Gallery’ and ‘Reservations’ – this meant that these pages could not be edited or deleted. The restricted was applied as each of the pages contained code that was required
in order for each of the components to function correctly on the website. Future development could allow for customisation of each of the components through the pages tab, rather than having no access to them at all.
Another feature of the system – the menu was implemented to allow the manager to have control over the customisation of menus on the fly. Whatever is input into the menu component, would show on the website through the menu page. The implementation of the menu feature was successful. Although, by hiring a graphic designer to create a menu – the customisation is more much extensive. Having said that, the feature that has been
implemented for the client is much more practical for every day web use. A graphic designer would produce a menu that is downloadable as a .PDF file. A limitation of this is that not every user that uses the web has a PDF viewer. The solution implemented for the client does not require a PDF viewer. It generates the menu directly to the customer in the form of a webpage.
The chef and supplier interfaces of the system also known as the Kitchen / Supplier tabs are based the ‘OpenCart’ software package. The problem in modifying a software package that is built for a specific purpose is that in doing so - a lot of code has to be removed and new code is added in order for it to function for its new purpose. Choosing to modify this package did result in a lot of time being wasted against removing many of the unwanted features the package came with. To build a shopping cart package is a project within itself. From a very early stage it was decided that the time involved in building a shopping cart from scratch would be much greater than the time involved in modifying an existing cart. Having said that, the supplier and kitchen components perform just as they should. The kitchen component provides the chef with an interface to make food orders to the supplier, who is able to manage what items are available to the kitchen. For future development, it would be preferred that such features be built from a framework such as CakePHP to ensure that no unnecessary features are implemented and no time is wasted removing them.
Given the time that was available to put the system together, the system does offer an extensive range of features that aid or automate the client’s restaurant in one way or another. Surprisingly, no software company has taken different components of a business and compiled them into one system. Although, as the system is a prototype - it is clear that there is definitely room to continue to develop the features. This could result in a greater
increase in the efficiency of running the business or even creating an environment in which the user feels more in control. This may consist of implemented additional customisation to features.