DCMI Government Community
|
Title: |
Functional Requirements for Describing ServicesDiscussion paper for DC-Gov |
|
Creator: |
John Roberts, Archives New Zealand |
|
Date Issued: |
2002-08-30 |
|
Status: |
Preliminary Draft |
Background
The DC-Gov Working Group meeting in Tokyo, October 2001 raised the description of services as an issue of significance to e-government programmes in various jurisdictions (see http://dublincore.org/groups/government/TokyoReport.doc). The Working Group decided that rather than work immediately on guidelines for the application of the DCMES to services, an attempt should be made to articulate the requirements of a service description. This would then serve as a guide for determining how the existing elements can best be used, and where extensions may be required. This paper provides a preliminary discussion of the issues and draft set of functional requirements for refinement in the wider DC-Gov community and as a basis for future work. The thinking in this paper draws particularly on the experiences of the New Zealand E-government programme.
What is a service?
E-government literature emphasises the importance of services, and in particular of on-line service discovery and eventual integrated on-line service delivery. However, there is no consensus on the definition of a service. To some extent, a service can be defined by considering what it is NOT. Services are not the same as either the organisation (or organisations) that deliver the service; neither should they be confused with documents which either describe the service (eg brochures, web pages) or are used in transacting the service (eg application forms).
Who are we describing services for?
There are a number of possible user communities for service descriptions. Each of these will benefit in different ways from the availability of systematic service metadata, and each in turn will have somewhat different requirements.
This paper gives priority to the discovery needs of citizens as potential users of services. This reflects the widespread view that services should represent a user-oriented view of the world, and the common desire of e-government programmes to make services more readily accessible to the public through the Internet.
Both agencies providing services and e-government programmes will wish to know different characteristics of services. For example characteristics such as the transaction volumes may help determine priority services for “e-enablement”, but are not considered relevant for citizen-centric service discovery.
What does a service description need to do?
Service descriptions should support the needs of a potential user to identify the options in respect of services that meet their needs. The following requirements therefore attempt to articulate the factors that a potential user will consider in determining whether to pursue engagement with a particular service. Discovery of a service involves enabling a user to transact and obtain benefit through the service.
1 Identification The user, the provider and the discovery system should have means of referring to the service in a meaningful and unambiguous way. Without the ability to clearly identify the service in question communication between the potential user and the service provider(s) will be significantly hampered.
a. There should be a meaningful name for the service
The user of a service will want to be able to refer to a service by a simple, meaningful name
b. There should be a unique reference for the service
It should also be possible to refer to a service in an unambiguous way, to avoid any confusion
2 Understandable The potential user must be able to understand what they can obtain from the service. Service discovery involves the potential user obtaining enough information about the nature of a service to evaluate the benefits delivered by the service, and therefore which service meets their need.
a. Any limits on the usefulness of the service (eg permit only applies in limited area or time) should be clear
b. It should be clear who to contact for more information about the service
This may not be the same party as actually delivers the service
c. Distinctions and similarities between services should be evident
Where multiple organisations deliver the same service, eg many councils providing a dog licensing service, the descriptions should be integrated
3 Accessible The potential user must be able to determine how to make use of or participate in the service. To be useful, service discovery must be understood as involving all details required to obtain the benefits delivered by the service. Information about how to access the service is fundamental to this.
a. It should be clear where the service is available
A service may be available at one or more physical or virtual delivery points. The potential user needs to know where they must go to obtain the service.
b. It should be clear through what delivery channels the service is available
Services may be available through multiple delivery channels, such as over the counter, free phone, by post, etc.
c. It should be possible to describe both services available on-line and off-line
While the discovery system may be provided electronically, it should be capable of describing all services delivered by a particular organisation or jurisdiction, including those delivered in the physical world.
d. Any technological requirements for accessing the service should be clear
Some services (or delivery channels) may have either hardware (eg minimum modem speed), software (eg client software) or other pre-requisites. The potential user should be able to identify such needs.
e. It should be clear when the service is available
Discovery systems may be continually available, even though the services described are not. Potential users need to be able to identify when they can engage with the service.
i. It should be clear at what hours the service is available
If the service is only available at particular hours (eg 9am to 5pm) this should be clear.
ii. It should be clear on what days the service is available
Services may be available only on certain weekdays
iii. If there is a seasonal variation in availability this should be clear
Services may be available only at certain times of year
f. It should be clear in what language(s) the service is available
Potential users will wish to know in what language(s) they can conduct business through the service (including ideally any variation by delivery channel or delivery point)
g. Any eligibility criteria for the service (eg age, citizenship) should be clear
Many services are only available to people meeting specific criteria. Potential users need to know this both to determine their eligibility and to ensure they can provide necessary proof of eligibility
i. Any documentary requirement should be clear
If any documents need to be produced in support of eligibility criteria, eg production of a birth certificate to prove age, users need to know this to plan their engagement with the service.
h. Any costs involved in using the service should be clear
Costs will be a major consideration for many users in determining whether they wish to access a service.
i. Any options of provider should be indicated
If the user has a choice at the level of either agency, or customer service officer level, these options should be indicated. This is similar to, but distinct from the delivery points (3a) above.
4 Evaluation of suitability The potential user should be able to assess whether the service described is suitable for their needs
a. If the service has a particular target audience, this should be made clear
A service may be available to a wide range of possible users, but designed with the needs of a particular client group in mind.
5 Establish trust Particularly in the on-line environment the establishment of trust is critical to encouraging participation. The factors that create such trust are still coming to be understood.
a. It should be clear who delivers the service
Trust is largely placed in organisations. Potential users of a service wish to know with whom they are dealing.
6 Accountability of service The basis on which the service is offered, and responsibility for it should be clear. The accountability for a service may be in a different organisation than that which delivers the service.
7 Relation It should be possible to relate the service to other services, and to other relevant resources
a. It should be possible for the user to describe the service at different levels of aggregation and still discover meaningful information
Different users and users under different circumstances will conceptualise services at different levels of aggregation, and will need to be able to discover information whether they seek the transaction level or program level articulation of the service. The description level in general should be based on the needs of potential users.
b. It should be possible to identify related documents
While services are different in some significant ways from documents, documents will refer to services, and also participate in transactions. Potential users will wish to also find related documents when seeking a service.
Use of these requirements
This set of draft requirements attempts to outline how potential service users will be using a service description. The requirements currently reflect a mix of outcomes and attributes. Not all users will seek all the information mentioned in the above requirements.
This draft can be refined in several ways:
a) Where requirements are expressed in the form of necessary attributes of a service, the way in which this information is used by a potential user should be teased out;
b) Attributes should also be mapped against the existing DCMES to explore the adequacy of the currently available elements; and
c) Consistent guidance on the usage of the elements for service description will be important for interoperability of service descriptions. This should proceed on the basis of understanding user needs.