Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 Review if this works at this level

I. Use Case Description

Use Case Name

Agreements concepts for industry semantics support

Use Case Identifier

FND-EXT-01

Source

EDM Council on behalf of financial industry participants

Point of Contact

EDM Council: Robert Trypuz

SEC-Creation / Revision Date

6/4/2019

Associated Documents

FND FCT slides 30 May / 04 June



II. Use Case Summary

Goal

Provide conceptual disambiguation for financial contracts

Requirements

This use case is realized indirectly, via FIBO Domain FCTs for SEC, DER, LOAN and others, in that this FND use case provides the conceptual glue / semantic disambiguation for concepts in those FIBO Domains.

Scope

FND/Agreements/Agreements

FND/Agreements/Contracts

Priority

N/A: Content is already developed

Stakeholders

Financial Institutions:

  • Security Master File – Back Office
  • Clearing and Settlement CDEs – Back office
  • Reporting – Middle Office
  • Compliance – Middle Office
  • Risk – Middle Office

Description

Summarize the use case, capturing the essential objectives (no longer than a page), including a quick overview, restated goals, and principal actor(s).

 

User stories, if applicable, and any narrative mapped from those user stories to usage scenarios should be included in the Usage Scenarios section, below.

Actors / Interfaces

List actors: people, systems, knowledge bases, repositories, and other data resources, services, sensors, or other “things” outside the system that either act on the system (primary actors) or are acted on by the system (secondary actors). Primary actors are those that invoke the use case and benefit from the result. Identify the primary actor and briefly describe role. 

 

Any actor that is external to or outside the control of the use case owner should be further described under Resources, below.

Pre-conditions

Identify any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case.  Any assumptions about the state of other related systems can also be stated here.  List all preconditions.

Post-conditions

Provide any conditions that will be true of the state of the system after the use case has been completed.

Triggers

Describe in detail the event or events that initiate the execution of this use case.  Triggers can be external, temporal, or internal.  They can be single events or a complex event that indicates that some set of conditions has been met.

Performance Requirements

List any known performance-specific requirements – timing and sizing (volume, frequency, etc.), maintainability, reusability, other “-ilities”, etc.

Assumptions

 

Open Issues

 

III. Usage Scenarios

 Provide at least two usage scenarios that flesh out the requirements outlined in the summary, including identification of requirements specific to any envisioned ontology or semantically-driven service or application.  Scenarios should be described as narrative, with supporting diagrams as appropriate.  In an Agile process, every user story relevant to the use case should be included and elaborated/rolled up into one or more usage scenarios, with a clear mapping from the user story to the scenario it is integrated in or mapped to.


 

IV. Basic Flow of Events

Narrative: Often referred to as the primary scenario or course of events, the basic flow defines the process/data/work flow that would be followed if the use case were to follow its main plot from start to end. Error states or alternate states that might occur as a matter of course in fulfilling the use case should be included under Alternate Flow of Events, below.  The basic flow should provide any reviewer a quick overview of how an implementation is intended to work.  A summary paragraph should be included that provides such an overview (which can include lists, conversational analysis that captures stakeholder interview information, etc.), followed by more detail expressed via the table structure.

...

Basic / Normal Flow of Events

Step

Actor (Person)

Actor (System)

Description


 

 

 


 

 

 


 

 

 


V. Alternate Flow of Events

Narrative:  The alternate flow defines the process/data/work flow that would be followed if the use case enters an error or alternate state from the basic flow defined, above.  A summary paragraph should be included that provides an overview of each alternate flow, followed by more detail expressed via the table structure.

...

Alternate Flow of Events

Step

Actor (Person)

Actor (System)

Description


 

 

 


 

 

 


 

 

 

 

 

VI. Use Case and Activity Diagram(s)

 

Provide the primary use case diagram, including actors, and a high-level activity diagram to show the flow of primary events that include/surround the use case. Subordinate diagrams that map the flow for each usage scenario should be included as appropriate

 

 

VII. Competency Questions

 

Provide at least 2 competency questions that you will ask of the vocabulary/ontology/knowledge base to implement this use case, including example answers to the questions.

...

Describe at least one way you expect to use the semantics and/or provenance to propose an answer to the questions. Include an initial description of why the semantics and/or provenance representation and reasoning provides an advantage over other obvious approaches to the problem. (optional – depending on the use case and need for supporting business case).

 

 

VIII. Resources

 

In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured.  These resources include the set of actors listed above, with additional detail, and any other ancillary systems, sensors, or services that are relevant to the problem/use case.

...

Resource

Type

Description

Owner

Source

Access Policies & Usage

(sensor or external service name)

 

Include a description of the resource as well as availability, if applicable

Primary owner of the service

Application or service URL; if subscription based, include subscription and any subscription owner

 

 

 

 

 

 

 

 

 

IX. References and Bibliography

 

List all reference documents – policy documents, regulations, standards, de-facto standards, glossaries, dictionaries and thesauri, taxonomies, and any other reference materials considered relevant to the use case

 

 

X. Notes

 

There is always some piece of information that is required that has no other place to go. This is the place for that information.

...