Use Case Template

Rationale for a Use Case Template

One of the group’s core targets is the identification of specific areas where standardization would have an impact on the capabilities and means of interaction between the different actors (citizens and public administrations, companies, etc.). Therefore, the group should:

• Identify areas where existing standards can be leveraged to improve the state-of-the-art of data integration (in a broad sense) in the context of Public Services.
• Identify opportunities for new standards
• Issue a set of recommendations and best practices

As said before, it is of paramount importance that the standards have an impact on a broad community, propose significant improvement or a completely new way of doing things. Therefore, this group will define a set of use cases that depict specific scenarios where an existing or newly proposed standard can prove its value and limitations. It is expexcted that, at a later stage, this effort may enable the creation of interoperable, standard software systems and tools that allow for the Seamless Integration of Data in the public sector.

When/if possible, the following information should be captured as well for each use case:

• impact - in terms of audience or improvement of a series of aspects.
• required existing standards, and need for new standards.
• limitations know at this stage.
• expected problems for implementation or deployment.
• tools expected to implement these recommendations
• ...

Use Case Wiki Template

Use cases can be specified using the wiki template Template:UseCase. The wiki page that specifies this template gives a small example of how the template can be used to specify new use cases. The Use Case Example page shows an actual use case specified with the template.

Using a wiki template has several benefits. First of all, all templates will have a uniform layout that can be changed in one place (at the template wiki page). Secondly, the template ensures that all available relevant information is provided, use cases can be compared, and a lack of information is made explicit. Thirdly, all use cases are automatically categorised under the Category:Use_Case category.

A single wiki page cannot be prevented from containing multiple use cases, though this is not recommended as the use case category overview only lists pages.

Please, name pages in a consistent way, eg. Use Case N - short name.

Use Case structure

The Use Case Proposals should be submitted using an agreed upon format. This paragraph presents the current view of the group on this format and is under discussion at this stage.

Identifier

A number we can use to reference the Use Case - just in case the Use Case Name is changed. (e.g. UC-EGIG-SID-001).

Name

The name of the Use Case (e.g. Citizen-to-Citizen Data integration via sms).

Problem definition

Define the problem that the standard aims to solve and proposed benefits. (e.g. This standard defines a framework for the development of …).

Target population

Identification or description of the target population of the use case – seen as the community where the use case would have its impact. Should refer to one or many of:

• Citizens. Meaning all citizens with the needed infrastructure. (e.g. a mobile phone or internet connection).
• Public Administrations. The benefit solves a problem or improves the situation for public administrations embracing the proposed standard.
• Specific community. When the use case targets a specific set of citizens
• Companies.
• etc.

Description

A description of the Use case, in terms of interactions of the different actors involved. It is important to highlight the areas in the use case where the proposed standard would play a significant role.

Target software

In case the standard can / should be deployed into a specific software piece, please identify it here. (e.g. the SMS standard should be implemented in mobile handsets, short message centres and related software – billing, rating, etc.).

Identified problems or limitations

A set of problems or limitations that can be identified at this point. The list should be as comprehensive as possible, trying to foresee:

• inherent limitations of the proposed interaction model.
• technical difficulties or need for unavailable technology at this moment.
• possible resistance to change
• deployment challenges

Related initiatives

Known related initiatives

Priorization

A conclusion on whether the use case has the critical mass for recommendation, and a justification (e.g low given its poor reach in terms of target population and dubious technical feasibility).