Functional Specifications have a habit of covering the whole requirement and treating every feature with equal importance. This is important for a functional spec.. The system has to work properly. However, it can be misleading for the UI Designer, who is left wondering about the ranking of features.

It is unlikely that the Users have analysed the quantity and frequency of the functional feature usage. Good User Task Analysis should give you the input required to rank the features according to functional necessity and usage. Such a feature ranking is extremely valuable input into the Domain Partitioning process for UI Design, as it gives us big clues as to where our focus should lie.

In Peter Coad's work on Object Modelling, he uses a technique of ranking features based on 2 lists. A first list ranking them by Customer Satisfaction if the Feature is delivered and a second list ranking them by Customer Dis-satisfaction if the feature were ommitted.

Strategy 1. List the most important User Roles / Job Functions involved with the proposed system

So what does most important mean? How is it defined? There is no absolute answer to this. In fact it will probably vary across the different Users for the System. So how do you go about compiling such a list. Ask the systems sponsors or users independently to produce their own list. Work from knowledge gained in user interviews and from user task analysis. Try to pull together a list which consolidates all the input you've been given. Look for the commonly occurring choices. When you have compiled a composite list try to get buy-in from the Users you are working with and then validate it with top management.

You should end up with a result which looks like this...

• Salesman,
• Accounts Clerk,
• Sales Manager,
• Warehouse Clerk,
• Chief Accountant

If you find that you just can't produce a result at this stage then put the results aside. It is no disgrace to fail to identify the most important at this stage. Perhaps you are in a domain where there is no most important subset of Users.

If you don't get resolution, at this stage, treat the combined total list which you have acquired as a secondary list - described below - then revisit it later when you have explored some of the specialist strategies for business analysis - later in this paper.

Strategy 2. List the most important tasks to be performed with the system.

Again, there is no absolute answer for the most important list. Again take multiple sources of input and look for the common ground. Try to ask at least one User from the set listed in Strategy 1. If there is no common ground then treat the list as a secondary list and move on. Later strategies will obviate the candidates for the most important list.

I find that a good question to obviate the answer is to ask "What tasks do you perform in a day?". Refine the answer to list only the tasks which have a relevance to the system scope.

Hopefully, the Users will give you a list which looks like this.

• Call Customer
• Choose Suitable Products from the Catalogue
• Find Goods in the Warehouse
• Disptach Goods
• Collect Monies Due
• Dispatch Invoice
• Approve Credit Limit
• Receive Returned Goods
• Dispatch Monthly Statement
• Send Refund

If no day is typical then ask "What are you doing today?" Make sure to get an explicit answer then ask what other things are likely to come up over the next few days. Try to isolate typical behaviour or gather the complete set of possibilities. This is wandering into the area of User Interviewing which is really regarded as an input to this User Interface Analysis phase.

The list we have gathered is long enough to try and break it down into a most important and a secondary list

Make sure to validate the list with top management. This is particularly true if top management will also be users. Top Management often perform tasks with a system which are not obvious to a lower ranking individual and are often rarely performed tasks but are of huge importance because of the business risk attached to the results.

For example, list the credit exposure to customers in South East Asia with outstanding debt beyond 3 months.

Strategy 3. List the most important artifacts / things in the proposed system, existing system or current process

The key here is to look for physical things which get passed around, or pieces of paper describing physical things. There may be specific forms in the domain which have blank spaces. The form is a description of a thing, such as a shipment of goods, the detail which goes into the spaces is the detail which identifies a specific shipment of goods. A specific shipment of goods is a thing.

Ask a range of Users to identify the Things that they work with or the Forms and Paperwork which identify or describe those things. Try to ask at least one User from the set listed from Strategy 1. Take the output and try to reduce it to a common list. If there is no commonality then that too is important information. You may have already discovered that a User and Task orientation is more appropriate than an Object orientation for the User interface.

Why should this be so? The answer is that you have discovered that different kinds of Users require different artifacts/things (objects) . They have no shared experience with the Things. So orienting the design around the Things is not helpful.

You should expect a list like this

• Credit Application Form
• Goods
• Catalogue
• Receipt
• Statement
• Invoice
• Dispatch Note

Identifying Things and Descriptions is one area where User Interface Analysis and Problem Domain Analysis overlap. Things and Descriptions are Archetypes for classes [ Coad 99 ]. The other Archetypes are Role Players ( including User Roles from Strategy 1) and Moments or Intervals of Time ( introduced in Strategy 4 ).

Naturally, there ought to be an overlap in analysis of the two problems as the User Interface must ultimately represent what is built in the Problem Domain section of a system. Archetypes help to obviate what is important about a system and it should come as no surprise that what is important must be important in both the User Interface and the Problem Domain.