Brunel Home EuroView Home Deliverables

3. Determine the Requirements

Before you can actually plan the introduction of a directory service you must clearly define exactly what you`re trying to achieve. Are you simply upgrading existing applications with modern technology? Are you introducing electronic directory for any of its specific properties (e.g. ability to distribute directory data)? Remember that the directory is capable of supporting a host of applications and so can replace existing services as well as (effectively) forming new ones. Starting with core functionality consider which services could employ the directory. Once you`ve composed a list of potential uses you can decide which ones will be practically achievable. The range of uses will be limited by resource factors such as cost, manpower and the ability of existing applications to interwork with the directory. Availability of usable data will also play a part. The gathering and dissemination of some addressing information will be defined processes, e.g. publication of the internal telephone book. Other information, such as role data or management structure, may not be obtainable as a single block of data and in a form ready for inclusion into a directory. Where a required data set is not immediately accessible new data gathering and management procedures will have to be installed in order to make the information `directory ready'. Take care, then, to consider current data practices before defining the functional specification.

3.1 Planning Functionality

Often functional requirements will stem from the usage of existing applications and non-electronic services that the directory might replace. Begin by listing services that could make use of the directory or can be categorised as directory services. This should give you a baseline from which to progress with a set of requirements. Current usage of directories and similar applications is likely to be more pervasive than you might initially guess. Here are some examples:

• Contact management systems.
• Paper telephone books (both internal and external).
• Functional directories and service listings.
• Personnel database.

Once a list has been compiled you'll need to look at these services and determine who uses the system, how it's run and how much effort goes into to maintaining the service. Look at those you've found to see if their operation could be effectively replaced by the electronic directory. You can do this by determining a few key facts:

• Precisely what information is provided? Is this information capable of being supported by the directory? For example, the directory is suited to handling document references, though not to the storage of documents themselves.
• Who or what (application) makes use of the service? This will give you a handle on how much actual usage of directory data already takes place. If the service is used by relatively few people and can be identified as a special need then the directory may not be appropriate. Administrative departments may need a relational database, for example, and the directory is not necessarily best equipped to support this function.
• What data sources are currently available and how they are kept up to date. How for example do the providers of the paper telephone book gather their data? The processes highlighted here may need upgrading to suitably accommodate the directory.
• What resource is already going in to the upkeep of the service? How much effort goes into creation and maintenance? Ideally management of the directory database will require a similar level of resource. This, though, is not an ideal world and so be prepared to accept an increased and consistent level of effort for ongoing maintenance of the database. Remember that where directories such as the paper phone book are kept up to date and published periodically, the directory can keep in step with changes as they occur.

3.2 Meeting User Access Requirements

The success of a directory service will be gauged by how well the service is perceived by its users. If high levels of user acceptance are not achieved then the directory will not be utilised to its potential. The user interface is key component of the service. Users are quickly discouraged if what they see isn`t friendly or fails to do exactly what they want it to. The directory provides a rich set of querying mechanisms and it is up to the user interface to translate these into an appropriate response to staff needs.

It is essential, then, that the user interface performs the tasks that users require of it. The following are important considerations:

• Searching. Does the interface support the kinds of searches required? Can it, for example, search using fields that users want to use as match criteria?
• Browsing. The ability to browse through directory contents is not a fundamental function, though many users like the interactivity that this "view" on the directory provides.
• Data presentation. Ensure that any client makes full use of the types of data that will be stored in the directory.
• Management capability. Interfaces for manual updates to the directory will be required.
• Application integration. The interface should be capable of integrating with other applications that require access to directory data.

Generic and user friendly search engines are difficult to design. This is because the shape and content of directory databases can vary considerably from organization to organization. This means that any directory client you adopt will have to be able to cope with the kinds of searches required, using your particular database structure and the data types it contains. If a user agent expects all searches to occur at a single point in the directory information tree this would prevent, for example, searches across a fully distributed directory.

Also be careful that the client allows you to search using the required criteria. Most clients will support White Pages searches (e.g. match on a personal name). Other searches (such as search on role) may not be supported. Similarly the way a client handles search input is also important. For example will the search string "J Smith" match entries containing "John Smith", etc.? It is very important that the match algorithm works well with the data contained in the directory.

Some clients allow the user to `browse' the directory information tree. Specifically, this means that the user is allowed to list entries below any selected node in the tree, e.g. list all departments beneath an organizational entry. This may seem useful on the face of it, as it adopts a fairly common user interface metaphor. There are, however, limitations to this form of usage, the main one being that many directory systems will be configured to prevent listing of all entries in the directory (especially if there are more than a hundred or so) in order to prevent database trawling.

3.2.2 Data Syntaxes

All information contained in directory is formatted according to a given attribute syntax. The `postal address' attribute for example is limited to six lines of thirty two characters. The `photo' attribute is in G3 fax format. For a client to handle a syntax it must be able to display data of that particular syntax and in some cases be able to make meaningful use of it - selecting a World Wide Web URL could invoke a browser, an e-mail address could raise a mail interface with a compose window, etc.. In the case of an administrative user agent it must also be able to modify data. 3.2.1 User Querying

Generic and user friendly search engines are difficult to design. This is because the shape and content of directory databases can vary considerably from organization to organization. This means that any directory client you adopt will have to be able to cope with the kinds of searches required, using your particular database structure and the data types it contains. If a user agent expects all searches to occur at a single point in the directory information tree this would prevent, for example, searches across a fully distributed directory.

Also be careful that the client allows you to search using the required criteria. Most clients will support White Pages searches (e.g. match on a personal name). Other searches (such as search on role) may not be supported. Similarly the way a client handles search input is also important. For example will the search string "J Smith" match entries containing "John Smith", etc.? It is very important that the match algorithm works well with the data contained in the directory.

Some clients allow the user to `browse' the directory information tree. Specifically, this means that the user is allowed to list entries below any selected node in the tree, e.g. list all departments beneath an organizational entry. This may seem useful on the face of it, as it adopts a fairly common user interface metaphor. There are, however, limitations to this form of usage, the main one being that many directory systems will be configured to prevent listing of all entries in the directory (especially if there are more than a hundred or so) in order to prevent database trawling.

3.2.2 Data Syntaxes

All information contained in directory is formatted according to a given attribute syntax. The `postal address' attribute for example is limited to six lines of thirty two characters. The `photo' attribute is in G3 fax format. For a client to handle a syntax it must be able to display data of that particular syntax and in some cases be able to make meaningful use of it - selecting a World Wide Web URL could invoke a browser, an e-mail address could raise a mail interface with a compose window, etc.. In the case of an administrative user agent it must also be able to modify data.

Particular syntaxes to watch out for are:

• labeledURI A World Wide Web URL.
• postalAddress A formatted postal address.
• jpegPhoto A colour image encoded using the JPEG scheme.
• photo A monochrome image encoded using the G3 fax scheme.
• distinguishedName A directory name.

Whatever your database maintenance strategy you`ll need a user interface capable of updating the directory database. This will handle the relatively irregular and small changes that occur as staff arrive, leave or move within the organization. The client should be able to add, delete and modify entries. The capacity to rename and/or move an entry is desirable, though not absolutely necessary.

Some support for bulk changes would be useful, for example moving entire groups of entries in a single user interface operation. However, be wary that interdependencies exist in the directory and any large scale movement of directory entries will invalidate existing references to those entries. Role entries containing pointers to the personnel that occupy them are an example. If the referenced personal entries are moved then the pointers from the role entries are broken. Ensure that any bulk operations within client software will take care of, or at least flag, such problems.

As with general directory clients the management interface must be suited to the people who will use it. If 'naïve` users are to be given the ability to manage the database then the user interface should hide technical aspects of the directory. Where appropriate information should be defaulted. For example when creating a new entry for a person, the client should use a template containing default values rather than relying on the user to enter them.

3.2.4 Platforms

Embedded directory user agents are a relatively unexplored area of development. So far integration has generally been limited to electronic mail interfaces, i.e. as an in-built mechanism for looking up intended mail recipients or populating an address book. Remember that the directory can contain many different kinds of information. As directory usage develops in coverage and information content further applications of this nature will become available. Recent developments have seen directory user agents embedded into word processors (for postal address insertion) and workflow applications where calendar and scheduling information is stored in the directory and linked to the entries of individuals and groups.

Clients are likely to integrate well, perhaps using a proprietary interface, with applications provided by the same vendor. Sometimes directory user agents will contain hooks onto a common interface (such as MAPI), which will make integration easier. In cases where no common interface is present specific solutions may have to be developed for a particular requirement.