Merge pull request #24 from rikoe/migrate-use-cases

Migrate use cases from use case repo

Author: Saori Fotenos

docs/assets/uc4.png

@@ -1,36 +1,34 @@
 ---
-id: use-case-1
+id: uc-1
 title:  "Use Case 1: Equity sell side trader"
-sidebar_label: Equity sell side trader
+sidebar_label: 1. Equity sell side trader
 layout: use_case
 ---
 
+## Preconditions
 On their desktop, this user has:
-- Their firm's proprietary research & analytics platform containing liquidity tools and internal research. The product is running and the liquidity tool is open
+- Their firm's internal research & analytics platform containing liquidity tools and internal research. The product is running and the liquidity tool is open
 - An installed chat application - product is running
-- A third party research & analytics platform with 3 open applications:
+- A third party market data terminal with 3 open applications. These applications are all 'linked' through a channel. 
     - A Watchlist
     - An Order Book
     - An Overview of pricing and fundamental data
-- A third party Charting Application hosted in a web browser
+- A third party Charting Application access via a browser window. This is not open. 
 
 ## Workflow 1
-The user receives a message in the chat application containing an instrument identifier for Tesla. They want to do some analysis on Tesla and so see what applications are available through right clicking on the identifier for Tesla. They have the option to launch an app in their proprietary platform, or in the third party platform.
+The user receives a message in the chat application containing an instrument identifier for Tesla. They want to do some analysis on Tesla and so see what applications are available through right clicking on the identifier for Tesla. A menu will appear within the chat application showing applications that can be launched from the Messenger tool. The menu shows two apps, both for analysis; one in the internal platform, the other in the market data terminal. 
 
 ## Workflow 2
-The user wants to see internally created and shared information on Tesla and so launches a proprietary research app that opens showing internal research published on Tesla.
+The user wants to see his firm's internal research on Tesla and so decides to open the analysis app from his internal platform. The application is launched showing all internal research available for Tesla. 
 
 ## Workflow 3
-The user wants to do further analysis on Tesla and so launches a third party research and analytics platform that opens showing financial statements and calculated financial data (such as market capitalization, P/E ratio, growth rate, earnings margins, etc)  and 3rd party research documents published on Tesla that they are entitled to access.
-
-## Workflow 4
-The user decides that they want to do some technical analysis. The third party platform has an integration with the third party charting application and the user launches the app, which opens in a browser window.
+The user wants to do further analysis on Tesla and so they open (themselves) a new app in the market data terminal that has Tesla's financial statement and other calculated financial data (such as market capitalization, P/E ratio, growth rate, earnings margins, etc). The user sees the third party charting app listed in a menu in the market data terminal and decides to do some technical analysis using that app. They select the chart app, which opens in a browser window. 
 
 ## Workflow 5
-The user wants to see information about another competitive international automobile company such as BMW.  The user changes the selected identifier from Tesla to BMW in one app in the third party platform and the open applications, including the charting application, change to show information on BMW instead of Tesla.
+Having done technical analysis in the Chart app, the user wants to do the same analysis on BMW, and also use the open pricing and fundamental app. The user creates a link between the financial statement app, the pricing data app (both in the market data terminal) and the charting app. The user changes the instrument in the financial statement app and the other applications update to show information on BMW. 
 
 ## Workflow 6
-The user adds BMW and Tesla to a shared group of companies (aka a Watchlist) named "Automotive comparables" to a list within the watchlist.   This group of companies is shared with all applications which use this group for any comparative analytics.
+The user adds BMW and Tesla to a shared group of companies (aka a Watchlist) named "Automotive comparables" to a list within the open Watchlist. All linked applications update with the new companies.
 
 ## Interoperability Points
 - API

docs/assets/uc5.png

@@ -1,48 +1,48 @@
 ---
-id: use-case-9
-title:  "Use Case 9: Client-side FX Trader Credit Check"
-sidebar_label: Client-side FX Trader Credit Check
+id: uc-9
+title:  "Use Case 9: Call Transcription to CRM"
+sidebar_label: 9. Call Transcription to CRM
 layout: use_case
 ---
 
-### Overview
+## Overview
 
 Voice calls contain important financial information which is trapped in the audio.  These data are not easily searchable; human notetakers are prone to error; and post hoc call notes may miss crucial elements.
 
 Real-time transcribed audio data, saved to a CRM or other record keeping system, increases data accuracy and saves users valuable time.
 
-### Persona(s)
+## Persona(s)
 
 Anyone who uses the phone to conduct business and needs to record contents.  Examples include:
 
 1. an analyst calling into an earnings call
 1. salesperson on a call with a customer
 1. a meeting attendee capturing their notes
 
-### Workflows
+## Workflows
 
 This transcription workflow consists of multiple workflows for gathering an audio stream.  Each of these Alternate Inputs below could use traditional telephony, or a software client.  The output of the finished transcription is sent to a CRM.
 
-#### During live call
+### During live call
 
 1. During a live call, which might be a group call with multiple users, one user conferences in transcription service.
 1. Parties converse as normal, while transcription service turns audio to text.
 1. At conclusion of call, transcription service sends completed transcript and metadata to CRM
 
-#### Post-call dictation
+### Post-call dictation
 
 1. After an event is concluded, the user initiates a dictation client (possibly a softphone)
 1. User speaks their notes into a microphone.
 1. Transcription service transcribes audio into text.
 1. Transcription service sends completed transcript and metadata to CRM.
 
-### Interoperability Points
+## Interoperability Points
 
 Each of these 2 handoffs:  client → transcription service → CRM , represent interoperability points for FDC3.  All 3 may be from separate providers.
 
 The transcription service → CRM handoff may have an intermediary step where the user selects the 2nd party in their CRM as target for saving (this may potentially be automated with sufficiently rich metadata), or even which CRM or destination to save the data.
 
-### FDC3 Working groups affected
+## FDC3 Working groups affected
 
 - Intents Working Group
-- Contexts Working Group
+- Contexts Working Group

docs/use-cases/2018-06-08-001-equity-sell-side-trader.md

@@ -1,14 +1,14 @@
 ---
-id: use-case-10
+id: uc-10
 title:  "Use Case 10: Real-Time voice trades -> trade ticket population"
-sidebar_label: Real-Time voice trades -> trade ticket population
+sidebar_label: 10. Real-Time voice trades -> trade ticket population
 layout: use_case
 ---
 
-### Persona:
+## Persona
 - Salesperson / Trader / Broker negotiating a trade via voice (over the phone).
 
-### Workflow
+## Workflow
 1. User is on a call with a customer.
 1. User conferences in Quote / Trade service.
 1. DURING the call, user dictates trade/quote prefaced by key phrase (e.g. “Confirm…”) to distinguish final quote from negotiation.
@@ -17,9 +17,9 @@ layout: use_case
 1. User may edit details, or correct errors.
 1. User submits ticket to quote capture service.
 
-### Interoperability Points
+## Interoperability Points
 The service which turns voice into structured text and metadata will need to send this data to a separate trade ticket service via FDC3 intents/contexts.
 
-### FDC3 Working groups affected
+## FDC3 Working groups affected
 - Intents Working Group
-- Contexts Working Group
+- Contexts Working Group

docs/use-cases/2018-09-20-009-call-transcription-to-crm.md

@@ -0,0 +1,26 @@
+---
+id: uc-4
+title:  "Use Case 4: Client-side FX Trader Credit Check"
+sidebar_label: 4. Client-side FX Trader Credit Check
+layout: use_case
+---
+
+## Preconditions
+
+- Running a client in-house proprietary application capable of conducting a user credit check
+- Running third-party trading app (e.g. Autobahn FX)
+
+## Workflow 1
+
+1. The FX Trader clicks button to book a trade in the third-party trading app (e.g. Autobahn FX)
+1. The trading app executes an interop action to the client in-house proprietary credit check application to check the trader's credit limit. If this check indicates the limit has been reached, the trading app presents a rejection dialog as a standard error dialog box with an informational message which may be a standard message (e.g. "Credit Limit Reached") or may include an interop link/action (provided by the credit check application) to resolve the limit breach.
+
+![Use Case 4 Workflow](assets/uc4.png)
+
+## Required Features
+
+- Point-to-point RPC invocation.  Current FDC3 API proposal doesn't define response message for "open" and "send" methods as they both returns `Promise<void>`:
+
+https://github.com/FDC3/FDC3/blob/master/src/api/interface.ts#L66
+
+https://github.com/FDC3/FDC3/blob/master/src/api/interface.ts#L34

docs/use-cases/2018-09-20-010-realtime-trade-ticket-population.md

@@ -0,0 +1,35 @@
+---
+id: uc-5
+title:  "Use Case 5: Buy side Treasurer - client rates across providers"
+sidebar_label: 5. Buy side Treasurer - client rates across providers
+layout: use_case
+---
+
+## Preconditions
+
+- Several trading applications from different providers - all running
+- UI which aggregates rates from different providers by entered parameters and allows to quickly execute trade with the most appropriate one
+
+## Workflow 1
+
+1. A Corporate Treasurer enters or chooses the required trade parameters in an aggregator app which then sends requests to different providers to subscribe to rates updates
+1. The aggregator app shows screen with all the rates received from the running provider apps and updates them in real-time as soon as provider sends new rate.
+
+![Use Case 5 Workflow](assets/uc5.png)
+
+
+## Workflow 2
+
+1. The Treasurer chooses one option to execute from the list of rates shown in the aggregator app
+1. The chosen provider app shows booking UI with pre-populated trade parameters
+
+## Workflow 3
+
+1. The Treasurer closes the screen with aggregated rates
+1. All the providers receive notification that listener has unsubscribed and they can stop providing updates
+
+## Required Features
+
+- Discovery
+- Ability to get invocation response as stream. Current FDC3 API proposal doesn't define API to get stream of responses
+

docs/use-cases/2018-10-02-004-client-side-fx-trader.md

@@ -0,0 +1,43 @@
+---
+id: uc-2
+title:  "Use Case 2: Buy side Portfolio Manager"
+sidebar_label: 2. Buy side Portfolio Manager
+layout: use_case
+---
+
+## Preconditions
+On their desktop, this user has:
+- An installed full-service market data terminal with news, quotes, research management, etc. The application is open and FDC3 compatible.
+- A third-party portfolio management system. The application is closed and not FDC3 compatible.
+- An installed application for the chat tool used by the firm. The application is open and FDC3 compatible. It also has a proprietary integration to the portfolio management system.
+- The default web browser for the OS.
+- The default mail application for the OS.
+
+On their mobile device, this user has:
+- The default mail application for the device.
+- The default web browser for the device.
+- The installed application from the market data provider.
+- The installed application for the chat tool used at the firm.
+
+## Workflow 1 (non-desktop)
+While using the mobile device (out of office), the user receives an email alert from his market data provider that a new research report has been posted which mentions a company that user is interested in. The user wants to read the report and clicks on the link in the email report. The market data application is launched and shows the research report.
+
+## Workflow 2
+Back in the office, the user wants to follow up on the report so he goes to his email client, finds the email and clicks the link. The market data application on the desktop displays the research report.
+
+## Workflow 3
+While reading the report the user wants to look up what the firm’s internal analysts have written about the company. The user hovers over the company identifier in the report and launches a tool within the terminal that shows the firm's internal research. A note from one analyst is intriguing so the user wants to know more. The user hovers over the name and launches the chat tool with a conversation with the analyst in focus and some details regarding the note is already posted to the chat.
+
+## Workflow 4
+During the chat, the analyst sends a link to a web site containing some further details regarding the company and the reason for the note posted. The user clicks on the link and the web browser opens. The user reads the article and continues to chat with the analyst.
+
+## Workflow 5
+During the chat, the analyst shares a chart with some important observations highlighted. The user clicks on the chart image in the chat and the terminal opens a live version of the chart with the observations highlighted.
+
+## Workflow 6
+During the chat, the user realizes that some changes should be done to their holdings in the company so hovers over the company identifier and launches the portfolio management system. While looking over the holdings the user also wants to contact the firm’s trader who is listed within the system. The user hovers over the name and launches the chat tool with a conversation with the trader in focus.
+## Interoperability Points
+- API
+- Intents
+- Context
+- Financial Objects Program