Within todays lecture we recapped the work we completed last week in relation to RAD (Rapid Application Development) and UML (Unified Modelling Language). Firstly we reminded each other of the different approaches to project management, then we looked at what the customer actually recieves as the project progresses. These were the outcomes:

• Phased Development - Customer uses a basic version (version 1) and additional upgrades (new version) are added constantly. There is a very quick devliery time using this version due to the initial version been produced at a basic level.
• Prototyping - Customer gets to use a version briefly and feedback is given back to the producer/team for upgrades and improvements.
• Throaway Prototyping - Customer only gets a design of what the system will look like, meaning they never actually get the final version, until the "Throwaway" stage is made.

Based upon how quickly the customer needs the system can often depend on which method to use in order to meet the customer needs, hence, the importance of choosing which approach to use is vital.

Prioritising Functions:

Two Functions - Version release to customer as early and possible, and if expectations are high BUT the budget is low, the product must contain essential elements. This basically means that when it comes to prioritising the elements within the database, either one of, or both of these aspects need to be taken into account prior to the build. If the company/person requesting the system is short of money, then the most important elements must be included first, so that the company/customer gets complete satisfaction.

Problems When Creating A System:

• When speaking to the customer, it is likely the customer will want EVERY aspect they require within the first version of the system, meaning that prioritising becomes a much harder job. This means that the creator of the system needs to stress that as later versions of the system are released (Phased Approach), then the less important features will be incorporate later. This can often be hard for the user to choose the key aspects of the system they want now and later.
• It can be very difficult to get customer to organise/create priorities. This often results in a long list of features within the system being handed to the creator, and the creator mapping out which features shoul be incorporated first. Occasionally, this can result in the person/company requiring the system to become nervous towards whether or not the system will fully meet their needs or not.
• Some functionality in the system may inter-link (i.e. independant). Sometimes functionality is inter-linked and can't be separated.

Prioritising Categories - Requirements Scales:

Following the list of features being handed to the customer, or the creator creating a list of features to be included within the system, a priority scale must be created so that the features can be released in an order that the most important features are included first, and the least important features last. The features that the user requires within the system must fit into one of the following categories depending on their importance:

• High Priority - Product is not acceptable without this function/feature. Sometimes the phrase "Mission Critical" is used as another name for the feature that MUST be included. The features/functions that are included in this category will be released in v1.0.
• Medium Priority - Supports necessary operation. Required eventually but not immediately (e.g. something that must be in the system, but can wait - Reporting Facilities etc.). Would enhance the system once included. The features/functions that are included in this category will be released in v2.0.
• Low Priority - It is nice to have these features within the system, if the budget allows us to include them (e.g. a newsletter that can be sent out to the customers/public etc.). The features/functions that are included in this category will be released in v3.0.
• Any later features will be released in versions 4.0 and above.

Steps To Follow To Prioritising

In order to reach the final result for prioritising features, the following steps must be taken:

1. Go through the case study and/or the project and list all the functions/features contained in the requirements.
2. Go through the list of functions/features and associate each of these with one of the prioritising categoires mentioned above (High, Medium, Low), AND state a reason why.
3. Set the list into descending order of importance, meaning that all the important features (everything in version 1.0) will be first.
4. Agree the list with the client.
5. Group features/functions into versions of release.