I. Use Case Description | |
Use Case Name | Index analysis for ETF development |
Use Case Identifier | IND-EFT-DEV |
Source | IND Content Team |
Point of Contact | |
Creation / Revision Date | 7/19/2019 |
Associated Documents | Requirements documentation, traceability matrix if applicable |
II. Use Case Summary | |
Goal | Enable development of a new fund whose performance can be compared to a benchmark |
Requirements | State any requirement(s)specific to this use case, including any capabilities from a business architecture or process model that the use case supports, any metrics or other reporting requirements, etc., including any reference identifier for the requirement(s), as applicable |
Scope | Coverage is limited to equity indices rather than indices that include credit indices or economic indicators for this use case. |
Priority | Identify the priority of the use case (with respect to other use cases for the project) |
Stakeholders | Traders who will be trading the fund based on the index, Compliance/Risk (for managing risk related to the fund), Clearing and Settlement Team (for trades related to the fund), Finance Team (for managing the fund flows if there are trades happening), Index Administrator, external stakeholders such as market data providers |
Description | A business analyst/front-office salesperson is interested in selecting one or more equity indices as the basis for predicting/comparing the performance of a new exchange-traded fund (ETF). This may require understanding the make-up of a benchmark based on a balance of small, medium, and large cap organizations, overall performance during some prior period, based on a mix of national and international instruments, based on avoiding being overly exposed to a single sector, company, or country, etc. in order to meet the performance goals of the fund, however the goal of this use case is for limited comparison. In other words, we will not necessarily create a number of sector classification schemes for this use case. In general, the goal is either for the fund to track the index or for its performance to exceed that of the index. This means being able to describe 10- 15 benchmarks that are commonly used, without detailed sector classification, but sufficient to distinguish one major index from another. This initial use case involves limiting the scope to equities only. We will create a subsequent use case to cover bond/debt indicies. We will only use content that is published about each of the indexes, and avoid assumptions about classification schemes (at least, in depth classification) for the purposes of this use case. Indices under consideration include:
Assumptions: The business analyst has a template for defining the contents of the fund provided by their organization that allows them to vary the index based on desired goals. For every index, information about the stocks that participate in the index must be provided (i.e., the list of stocks). If there are derivatives based on the benchmark, then links to those derivatives must be provided (all done by the reference data team). |
Actors / Interfaces | People: Business Analyst developing the fund, Index Administrator (entity that manages the index), Issuer of the constituents of the index (maybe) Systems:
There may be another actor that represents the fund, or another system that needs to access information about the index, in addition to the above.
|
Pre-conditions | N/A |
Post-conditions | N/A |
Triggers | Index creation, corporate action such as an M&A action that causes the constituent of the index to cease to exist |
Performance Requirements | N/A |
Assumptions |
|
Open Issues |
|
III. Usage Scenarios
Use cases proposed by Ashwin via JIRA include the following, which we will flesh out into more complete scenarios:
- Get the value of Index at any point in time. Optionally the user can seek details of the constituents' contribution to the movement of index value from a particular point in time (e.g. previous day's close)
- As a user of the Index service, I need to be able to get all the details of the constituents of the Index including the weightage and other details
- To ensure stability of the index, the index constituents are changed at regular interval. Whenever this is done there is a need to "rebalance" the index so that the change in constituents does not change index level abruptly
- There are certain corporate actions of the Index constituents (like stock splits and stock dividends) that require changes to be done to the Index data maintained. Other examples are share issuance and these require adjustments to prevent the value of index from changing.
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.
In cases where the user scenarios are sufficiently different from one another, it may be helpful to describe the flow for each scenario independently, and then merge them together in a composite flow.
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
- What are the constituents of this index as of a given date?
- What is the value (price) of this index on a certain date? What are the prices for the constituents of this index as of this date and how are they weighted?
- What indices have a given equity as a constituent as of a given date?
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.
Knowledge Bases, Repositories, or other Data Sources
Data | Type | Characteristics | Description | Owner | Source | Access Policies & Usage |
(dataset or repository name) | (remote, local/in situ, etc.) | e.g. – no cloud cover | Short description of the dataset, possibly including rationale of the usage characteristics |
| Source (possibly a system, or remote site) for discovery and access |
|
|
|
|
|
|
|
|
External Ontologies, Vocabularies, or other Model Services
Resource | Language | Description | Owner | Source | Describes/Uses | Access Policies & Usage |
(ontology, vocabulary, or model name) | (ontology language and syntactic form, e.g., RDFS - N3) | If the service is one that runs a given ontology or model-based application at a given frequency, state that in addition to the basic description |
| Source (link to the registry or directly to the ontology, vocabulary, or model where that model is maintained, if available) | List of one or more data sources described by and/or used by the model |
|
|
Other Resources, Service, or Triggers (e.g., event notification services, application services, etc.)
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.