To implement any plug-in for the WAF, it is necessary to create the WAF first. That's why the requirements are split up into three parts: the WAF, the Sort Code System and the Google Contact Application.

To prioritise the features and to show something like a hierarchical structure (some features may part-depend on others) the MoSCoW[1] method is used in this section.

• Global managed database access
  A global interface which provides standardised access to the database. It should handle errors and simplify the data access.
• Storing global variables
  Informations like database connection arguments, the own server address or the administrator password must be saved somewhere. Instead of hard code them into the system, this module allows it to modify this settings.
• Generic classes to create objects or lists from database results
  A class which can be created out of a complete database result row. Out of the creation the object knows every data-field (member variables) and provides getter and setter methods for these fields as well as save and delete methods.
• Template based
  The system should not mix program logic code with the design. In the templates files should be only design code!
• Error handling and error analyse systems
  Instead of printing out the system errors of the client, the WAF system will store them to provide a good maintenance and debug feature with these data.

• Structured URL system with URL rewriting system
  A global data structure which stores every URL in the system together with the linked module and the modules parameter. The rewriting should make the URL's more search engine friendly.
• Different administrators (includes a super administrator):
  • administration of administrator privileges
    specifies which administrator is allowed to access which module and which content he is allowed to edit / delete / create
• logging of actions
  to have a history of all transactions, every altering action should be logged to the system

• Caching
  Almost every website has static and dynamic content. The dynamic content has to be generated with every request, but to improve the performance it's better to cache the static content (content that doesn't change very often) and update it only every few hours.
• Installation routine
  Because of the reusability, the system should have a routine which does all the system setup stuff automatically.
  • create the database tables
  • check and sets the folder privileges
• System check feature \\All the installation steps must stay resistant. And because of changes from third persons, a check feature would be nice for maintain purposes.
  • checks the database integrity of the basic system
• checks the folder privileges

• Version controlling of the plug-ins / modules
  Checking the version ID from a global website and notify about outdated files.
• Plug-in template editor
  A template editor which enables users without HTML knowledge to edit the plug-in templates. With that, users could do colour or positioning changes online – without uploading files via FTP.
• Automatic database backup
  In case of a system crash, it is necessary to have actual database backups of the whole content. This feature should generate the database backup itself and store it disjunct from the database server.

The Sort Code System is about the German bank sort codes. It should be a sort code information system which receives all German bank branches with the linked sort codes and provide them to the WCA user in a searchable interface. It must also be possible to amend the imported sort code and branch data from the administration area.

The MoSCoW method can't be used for the requirements of this application, because they are depending on each other. Without requirement A, requirement B doesn't make any useful sense. The requirements are ordered into a hierarchical structure to show the dependencies (the higher numbers depends on the lower ones).

• 1 The database design of the sort codes and branches
• 2 Import feature of the sort codes and branches
  The national bank of Germany releases in irregular dates a new list of sort codes and branches.
• 3 Management of the branches \\In the administration of the system, it should be possible to change and add additional information to the branches – used mostly for advertising.
• 3 Sort code search
  The result is a list of every branch which contains the searched sort code.
• 3 Branch detail page
  A page which displays all information about one specific branch. The most of this content should be edited in the administration panel.

We have a three-tier structure here. Without the first and the second part, the rest would be useless and not realisable. The tasks from the third section describes the specific features of the sort code system, which the user can directly access and see on the screen (use cases).

The Google Contact Application is a client application of the Google Contacts which are provided from a Google Account[17]. That means in detail that this WCA should provide similar functionalities like the official Google Contacts Client on http://www.google.com/contacts:

• Display Contacts (this implies a login to the Google Server)
• Edit a Contact
• Delete a Contact
• Create a new Contact

This WCA application doesn't need an administrative interface like the sort code program has.

• Summary
• Introduction
• Requirements analysis
• Literary Review
• Architecture Design
• Implementation
• Testing and Evaluation
• Conclusion