UC:Use cases: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Line 5: Line 5:
<div id="t*"></div>A use case can be defined as ''a single task, performed by the end user of a system, that has some useful outcome''[[#*|*]]. It is described as a list of steps (actions or events) to achieve this outcome.
<div id="t*"></div>A use case can be defined as ''a single task, performed by the end user of a system, that has some useful outcome''[[#*|*]]. It is described as a list of steps (actions or events) to achieve this outcome.


What distinguishes a use case from an example is, that examples will typically consist of pieces of {{rml}}-code, whereas use cases will typically be formulated in natural language or ''Unified Modelling Language'' (UML). Examples are solutions (to nutshell problems). Use cases are descriptions.
What distinguishes a use case from an example is, that examples will typically consist of pieces of {{rml}}-code, whereas use cases will typically be formulated in natural language or ''Unified Modelling Language'' (UML). Examples are solutions (to nutshell problems). Use cases are descriptions (to nutshell tasks).


In the case of {{rml}}, use cases will typically deal with the exchange of data between two systems. The use case should then illustrate the system requirements to achieve the data exchange.
In the case of {{rml}}, use cases will typically deal with the exchange of data between two systems. The use case should then illustrate the system requirements to achieve the data exchange.
==What makes a good use case?==
==What makes a good use case?==
A good use case should be ''complete'', ''comprehensible'' and ''practically relevant''. Ideally, it should be ''perceivable by the public'' (A problem that can be understood and occur to everybody is more illustrative than one that only occurs to a small subgroup of users). Finally, the use case should be ''objective'' in the sense that it is not biased to the requirements or solutions of a certain organization or company.
A good use case should be ''complete'', ''comprehensible'' and ''practically relevant''. Ideally, it should be ''perceivable by the public'' (A problem that can be understood and occur to everybody is more illustrative than one that only occurs to a small subgroup of users). Finally, the use case should be ''objective'' in the sense that it is not biased to the requirements or solutions of a certain organization or company.

Revision as of 17:16, 23 February 2016

In this page you learn how to contribute good Use Cases.

While the emphasis of the railML®-wiki lies in documenting single elements in a bootom-up-approach, we also try to help users to capture the concepts of railML® via examples and use cases in a top down approach.

What is a use case?

A use case can be defined as a single task, performed by the end user of a system, that has some useful outcome*. It is described as a list of steps (actions or events) to achieve this outcome.

What distinguishes a use case from an example is, that examples will typically consist of pieces of railML®-code, whereas use cases will typically be formulated in natural language or Unified Modelling Language (UML). Examples are solutions (to nutshell problems). Use cases are descriptions (to nutshell tasks).

In the case of railML®, use cases will typically deal with the exchange of data between two systems. The use case should then illustrate the system requirements to achieve the data exchange.

What makes a good use case?

A good use case should be complete, comprehensible and practically relevant. Ideally, it should be perceivable by the public (A problem that can be understood and occur to everybody is more illustrative than one that only occurs to a small subgroup of users). Finally, the use case should be objective in the sense that it is not biased to the requirements or solutions of a certain organization or company.

Structure

Use cases are usually assigned to a subschema. The article name should follow the paradigm <subschema>:US:<use case>, e.g. IS:UC:Timetabling.

In railML®, use cases are usually presented with the following structure (which, too, can be seen in the example IS:UC:Timetabling):

  • Description: A sketch of the task, the necessary steps and the requirements in general.
It is important to note, to which railML®versions a use case or certain aspects of it apply, as use cases will devellop further with the develllopment of railML®.
  • Data flows and interfaces
  • Interference with other railML® schemas
  • Characterizing Data
    • How often do the data change (update)?
    • Which views are represented by the data (focus)?
    • Which specific timetable data do you expect to receive/send (elements)?

How to contribute a use case

  1. Please, coordinate with the coordinator of the respective subschema before making a sub case. Feel free to start an article in your userspace at your own risk.
  2. Develop the use case according to the mentioned criteria (especially #structure and #What makes a good use case?).
  3. Let the subschema coordinator review the article.
  4. Publish the article. Don't forget to version the use case and match it with the railML®-versions to which it applies — both the use case and railML® will evolve in the course of time. Please enter the article into the use case collection of the respective subschema, as in #Lists.

Lists

As use cases refer to certain subschemas, they are listed along this line:

References