P. 1
Execution Only BusinessFunctional Spec 1.0

Execution Only BusinessFunctional Spec 1.0

|Views: 0|Likes:
Published by Milind Tembhurne

More info:

Published by: Milind Tembhurne on Jun 28, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

06/28/2012

pdf

text

original

Business and Functional Specification Document I - ORF PBGO LD Customization for Execution Only Opportunities - ORF

Prepared By: B.V.Narayanan Version: 0.21.0

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

Page 1 of 22

For internal use onlyFor internal use onlyFor internal use only

Revision History Prepared By: B.V.Narayanan, (Balasubramanian.N01@mphasis.com) Revised By B.V.Narayanan Date Revised 26/09/2011 Version # 0.1 Main document Data capture on Execution DMA and Voice and Acknowledgement Opportunity type to be captured at the Give-Up agreement level instead of ORF level Execution mode and execution rates capture made applicable only on opportunity type ‘’standard’’ Use cases detailed with 10 more alternative scenarios ORF process structure re-drawn to reflect the aforementioned business requirement changes Mockup changed to reflect the requested changes as much as possible Review and changes recommended by business (Nidhi-R Gupta) incorporated: multiple sales-relationship owner on a Give-up agreement, mock up to reflect relationship owners and Voice & DMA rate hyper link to capture common rates, as well as fields to capture hyperlinks as typed input, copy, cut, paste etc; inclusion of relationship owner in the user case and an additional use case as well as the correction to the globe client and clear visions team on entering tasks in support Date: 26-09-2011 Changes

B.V.Narayanan

11/10/2011

0.2

B.V.Narayanan

14/10/2011

1.0

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

Page 2 of 22

For internal use onlyFor internal use onlyFor internal use only

Table of Contents

1. Introduction ................................................................................................................................................. 5
1.1 1.2 1.3 1.4 1.5 1.6 1.7 Background .................................................................................................................................................................5 Purpose ........................................................................................................................................................................5 Scope ............................................................................................................................................................................5 Impact of proposed Changes .....................................................................................................................................5 Intended Audience .....................................................................................................................................................6 Assumptions ................................................................................................................................................................6 Definitions and Acronyms .........................................................................................................................................6

2

Data Models and Process workflows ........................................................................................................ 7
2.1 2.2 Existing PBGO data model ........................................................................................................................................7 Current LD Process Workflow ..............................................................................................................................78

3

Functional Requirements ......................................................................................................................... 8
3.1 3.2 Actors ..........................................................................................................................................................................8 Use Cases .....................................................................................................................................................................9 UC 1 – Create new opportunity for Execution Only ........................................................................................9

3.2.1

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

Page 3 of 22

For internal use onlyFor internal use onlyFor internal use only

References & Acknowledgement

RFERENCED ITEM Primary mock-up on Execution only for Voice and DMA All functional and business requirements provided by telephonic discussion and interviews Existing PBGO Nidhi-R Gupta

OWNER

Nidhi-R Gupta

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

Page 4 of 22

For internal use onlyFor internal use onlyFor internal use only

1. Introduction
1.1 Background
Deutsche Bank’s Listed Derivatives, a division of Global Client Solutions, is a top tier provider of Execution and Clearing products, services and solutions to financial institutions. The term client opportunity by a client or potential client results in additional revenue to Listed Derivatives. These opportunities include, but are not limited to, the establishment of a new relationship, the addition of a Legal Entity to an existing relationship, the addition of a trading relationship/sub-account, or a request by an existing client to trade in additional products/markets. Transitioning a client opportunity involves not only the coordination of operational tasks and receipt of required documentation, but also communication among the various groups involved in the transition processes, which include the opportunity approval process, the creation of a document pipeline, establishment of credit/margin terms, and system setups. PBGO customization has been carried out for LD towards Execution and Clearing products so far.

1.2 Purpose
In order to improve the efficiency and overall functionality of the current client onboarding process for Execution only (through Voice and DMA). This will not only replace the current Execution only process in the PBGO, but a complete revamping, re-engineering of the entire process: the management of the three party, four party relationship on the give up agreements; capture and upload of different rate schedules on the relationships; addition of new relationships; amendment of existing relationships; emailing to different teams at different stages of onboarding with information to complete appropriate operational tasks ; to provide entitlement driven access from sales desk to operations . The current system, process will be replaced by a flexible, and streamlined system that meets the growing needs of the business and will serve as a centralized source of information for Deutsche Bank users involved in the client on boarding process for Execution only through Voice & DMA.

1.3 Scope
    Document the associated process and data workflows for Execution only customization of PBGO. Define and document the business requirements, system requirements (functional and non-Functional) agreed to by all stakeholders. Understand the placement of functionality and constraints within the PBGO Document the entitlement requirements of different teams

1.4 Impact of proposed Changes
Current functionality in Actors Priority PBGO Create Execution Opportunity type Sales person, High Only Opportunity classification, sales desk head – business and person(s) managing
Functional specifications Part I Page 5 of 22

Use Case

Functionality

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

For internal use onlyFor internal use onlyFor internal use only

system use case

the give ups , desk owner, structure give up agreement relationship(s) details(3 or 4 party), capture execution modes required, capture execution mode details and upload the associated rates on the give up agreement(s) Assign transition System will provide a Currently system coordinator – provision to assign a provides a provision to System use case transition coordinator assign a transition coordinator and credit/legal transition coordinator

1.5 Intended Audience
The intended audience for the document is:    Deutsche Bank business users (for Listed Derivatives) Deutsche Bank technical team Mphasis development team

1.6 Assumptions 1.7 Definitions and Acronyms
DEFINITION/ ACRONYM CTS PB-GO ORF Party Client Transition System Prime Brokerage Global On-Boarding Opportunity Request Form Party refers to the Trader, Customer, Executing Broker, Clearing Broker in the context of Execution only Parent is the owner of the Legal Entity. An application where all Give up agreements are uploaded, stored and an egus id is generated Page 6 of 22 EXPLANATION

Parent EGUS

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

R&N

Ralph & Nolan applications where all execution and clearing ledger accounts are set up User with administrative rights in the system. To be detailed/To be determined

Admin TBD

2 Data Models and Process workflows 2.1 Existing PBGO data model
The diagram below is a high level entity model that was deployed for all LOBS including Listed Derivatives.

Parent 1

Has

* Legal Entities * *

Managed by (Maping)

*

Investment Manager

Contains

* Products *

Available in (Mapping)

*

Regions

1

Has

* Accounts

2.2 Current LD Process Workflow

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

Page 7 of 22

For internal use onlyFor internal use onlyFor internal use only

3 Functional Requirements 3.1 Actors
Actors Salesperson Description Responsible for managing Give up relationships with Clearing Brokers on Give up agreements of an Opportunity request. Sales person will be able to capture New opportunity Entitlements a.) New opportunity – creation of new ORF under Give up agreement/execution only b.) View ORF and add new give up agreement to an existing ORF a.) New opportunity – creation of new ORF under Give up agreement/execution only b.) View ORF and add new give up agreement to an existing ORF (new functionality) Transition coordinator team a.) Enrichment b.) Support pipeline c.) Amendment of existing ORF (new functionality) (standard data) d.) Assign transition coordinator

Desk head

Equivalent manager

to

current

sales

DB Client team

They manage the DB client id set up; for execution only opportunities DB Client id is set up after an EGUS id has been set up on every give up agreement Log into support and will have access to enter and update R&N ledger Log into support and will have access to enter and update DOMS client code

Support pipeline – specific task to update DB client id in the PBGO

R&N team

Support pipeline – specific task to update R&N in the PBGO Support pipeline – specific task to update DOMS client code in the PBGO Support pipeline – specific task to Page 8 of 22
Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

DOMS Client code team GM LD TMG

Log into support and will have access to enter and update client Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

Global Clear Vision set up team

Globe code Log into support and will have access to enter and update Clear vision code Clearing vision application and sets up clearing codes; they log into PBGO support and record completion of the task Special privilege within transition coordinator team the

update the client globe code Support pipeline – specific task to update DOMS clear vision code in the PBGOlogs into PBGO and record the completion of clear vision set up

Transition coordinator BOW super user

To add new trader to the existing trader list To add new customer to the existing customer list To add new Clearing broker to the existing Clearing broker list To add new Executing broker to the existing Executing broker list To perform an amendment that involves a change to the existing party name (due to change in the legal name of any of the party) Include entitlement to add additional names/teams to the following email notification list: Live notification, completed notification (to marketer), R&N team, QA team, GM LD TMG, DOMS Client code team & Clear Vision team

DB Admin

The management will be using the system for MIS reporting. The administrator for the system.

3.2 3.2.1

Use Cases UC 1 – Create new opportunity for Execution Only

3.2.1.1 Brief Description The use case details the functionality for initiating a new opportunity for Execution Only through Voice or DMA or both. Sections have been detailed out to cover the business aspects and system aspects. In execution only opportunities what is being onboarded is a relationship among different parties, primarily a three-party or a four party relationship with always a Give-up agreement with the clearing Functional specifications Part I Page 9 of 22

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

For internal use onlyFor internal use onlyFor internal use only

broker. An ORF might have multiple give up agreements, but each of the Give-up agreement is completed (onboarded). 3.2.1.2 Actors Sales person, desk head 3.2.1.3 Preconditions     The user is already logged-in to the system. The user must have the right to create a new opportunity for Execution only customer requirements New PBGO menu option under Create New Opportunity, ‘’Give-Up agreement’’, ‘’New DB Execution Only’’ is added .The user is able to access the new menu option Give-up agreement, DB Execution only in the PBGO

3.2.1.4 Business Rules   There are three types of opportunity types on Execution only Give-Up agreements: Standard, EFP, LME; there will be no opportunity type at ORF level An ORF requestor from one geographical region must be able to choose a sales person from a different geographical region: basically list of sales person must be a global list and will independent of region; this replaces the current way of allowing users to select the sales person list A single sales person must be able to raise multiple give up agreement; the number of give up relationships on an ORF will directly depend upon the number of clearing brokers required for ‘’Giving Up’’ A Give-Up agreement might have multiple sales-relationship owners (also called marketer, sales persons) associated with it A sales person must be able to create relationship on a Give-Up agreement using the following  Clearing Broker  Executing Broker  Trader (Used 80% of the time)  Customer (will be defaulted to ‘’Disclosed by Acct Nbr’ , 90% of the time trader is used) and will be disclosed the remaining 10% of the time when trader is used  Customer with no Trader in 20% of cases Every Give-Up agreement will be classified under one of the opportunity type: Standard, LME (London Metal exchange), Exchange for Physical (EFP) A Give-up agreement with no trader is referred as a three-party agreement A Give-up agreement with trader is referred as a four party agreement whether default customer name is used or customer name is disclosed Many a time a party involved in a Give-up agreement as a trader can be a Customer when it comes to three party agreement, business will make use of such associations; In short a trader in a giveup agreement will end up as a customer in a different Give-up agreement Each Give-up agreement will have only one clearing broker associated with it An ORF that has arisen at the request of a trader will give raise to a four party agreement, though multiple give up agreements can be raised on the same opportunity, with some of the Give-Ups disclosing the customer name and some of them using the default customer name Every Give-up agreement will carry a relationship owner from DB (the sales person is in fact a relationship owner to manage the relationship with a specific clearing broker) A Give-up agreement that is of opportunity type Standard only carries the detail of the execution mode used by the trader/customer. The following execution modes are applicable: Voice, DMA, Voice & DMA Page 10 of 22

  

       

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

 

 

  

   

Voice related information and/or DMA related information will be available with the business either when raising the opportunity or later when enriching the ORF (this is similar to product level information captured on Execution DMA and Voice Execution – please see ); Again this data capturing is applicable only on Give-Up agreements of type ‘’Standard only’’ Hyperlinks link (instead of the execution rates, the user will enter the hyperlink where the rates are stored) on Rates will be captured at the execution mode on Give-Up agreements of type Standard only; Again rates may be available when the Opportunity request is raised or may be available and uploaded at Enrichment A provision just to enter commission that is most likely to be zer0 will be provided when the opportunity type is LME or EFP. A customer might choose Voice and DMA, might have separate rate provided by the sales person on each; so there may be two rates links (instead of the execution rates, the user will enter the hyperlink where the rates are stored) that will be captured one on voice and one on DMA (applicable only on Give-Ups with opportunity type ‘’Standard’’) A customer might choose Voice and DMA, DB might provide one rate, hence one rate link (instead of the execution rates, the user will enter the hyperlink where the rates are stored) may be captured (applicable only on Give-Ups with opportunity type ‘’standard’’) Business might use the same rate used on one Give-up agreement on other Give-Ups within the same ORF when creating a new opportunity or when adding a new relationship to an existing ORF (See View ORF – Add new relationship); It is highly likely that the business would like to use the same execution mode, same data captured against the execution mode as well as the hyperlinks captured on the execution modes to another Give-Up agreement In addition to an existing list of Customers, Traders, Executing Brokers, Clearing brokers business will require a provision to add any new Customer, Trader, Executing broker and Clearing broker, though this will be carried out by an entitlement different from sales person and desk head A Give-up agreement has different statuses based on the progress made towards its completion; When an Opportunity is created the Give-up agreement is deemed to be ‘’In progress’’ state by the business An ORF could have multiple Give-up agreements: every Give-up agreement is individually taken from in-progress to completion; Multiple Give-up agreements starting at the In progress stage can be completed at different points in time, hence may have different statuses between in progress and completed (going through stages of enrichment and support) A Give-up agreement can carry the following status: In progress, EGUS-Executed, Completed, Hold, Deleted, Expired; When creating the Opportunity request, it is defaulted to ‘’In progress’’ status Different Execution rates can be uploaded to the same Give-up up agreement on the mode of execution where the Give-Up agreement is of type ‘’standard’’ Client contact types will be Broker, trader and customer A contact used as a trader in four party agreement might be used as a contact when setting up a third party agreement i.e. when trader becomes a customer and vice-versa

3.2.1.5 System Rules      Every ORF should have a unique ID. The ID generated for Execution only ORF will be system generated unique number appended with ‘NGU’. System will provide a provision for the user to select a sales person name as a single select from the sales list; system must display a global sales list provided by the business System will provide a provision for the user to select a desk head from a list of desk heads; system must display a global list of desk heads System will provide a single select from the following list of opportunity types on each of the GiveUp agreement: Standard, EFP, LME System will provide a provision for adding multiple sales-relationship owners on a Give-up agreement; the sales-relationship owners list will be the sales person list Page 11 of 22

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

      

  

  

  

System will provide the provision to the user to add multiple Give-up agreement:; An addition + button can be provided to add another multiple Give-up agreement as shown in the mock-up System must provide the provision to add a three party or a four party Give-up agreement Where it is a four party Give-up agreement, customer name may be defaulted to a standard text or may be disclosed System will display a pre-populated list on Trader, Customer, Executing Broker, Clearing Broker and will provide the framework as per the business rules outlined System will provide an option for the user to choose whether execution rates have been received or not on Give-Up agreements that are of type standard that is mandatory: If the opportunity type is LME or EFP system will disable the yes, no buttons and will display the ‘’NA’’ and enable it Every Give-up agreement gives the user provision to choose an execution mode: Voice, DMA, Voice & DMA only on the Give-Up agreements with opportunity type as ‘’Standard’’ System will provide a provision to upload capture execution rates hyper link against the execution mode; the upload process need to cater for word, excel, pdf etc (applicable and mandatory only on the Give-ups with opportunity type as ‘’standard’’); this becomes mandatory on ‘’standard’’ opportunity types where user had marked the execution rates have been received;, where user has marked the execution rates received as ‘’yes’’; where user has marked the execution rates received as ‘’No’’ the system disenables fields that capture the hyperlinks on execution rates and the date the execution rates were received; these hyperlinks might be typed, copied, pasted, cut by the user and the system must allow that User may select Voice, DMA and upload separate rate links on them (applicable and mandatory only on the Give-ups with opportunity type as ‘’standard’’) where execution rates have been received with the date User might select Voice & DMA and might upload one rate link (applicable and mandatory only on the Give-ups with opportunity type as ‘’standard’’) where execution rates have been received with the date they have been received System will allow update the capture of s rate upload-link on a Give-up agreement at ORF, this can later be changed t at enrichment, until the Give-up is completed or during Amendment (please see Amend ORF functionality after the ORF has been completed); the user will select the link and will be directed to sharepointSharePoint where the user will be able to access the document (where the Give-Up agreement has an opportunity type as ‘’standard’’) When opportunity is created an execution rate might not have been received, r the execution rate-link might be uploaded entered (copied, typed, pasted, cut) at a later date at enrichment on the Give-Up agreements that are of opportunity type standard An ORF’s first Give-up agreement will not carry provision to copy the date the execution rate has been received and all the information associated link o f with the execution rate The first Give-Up agreement of type standard can serve as a template for other Give-Up agreements of type standard within the ORF: the date execution has been received, the execution mode(s), the data capture on the execution modes, the execution rates-upload link all of them can be taken to another standard give up agreement; this will save re-entry by the user An execution rate uploaded on a Give-Up agreement against a certain execution mode, must be made available to be used when adding another give-up agreement in the same ORF or even adding a new relationship to an existing ORF, but within the same ORF on the Give-Up agreements that are of opportunity type standard only A Give-up agreement can be physically deleted when the ORF is in a draft status or when the ORF is getting created before submitting it System must be providing provision through a different place holder and special entitlement to add new trader, customer, clearing broker, sales person, desk head To save and generate an ORF either as a draft or confirm and submit it, it is sufficient for a user to enter whether it is a three party or four party agreement, the opportunity type, the status of the Give-Up agreement, the sales-relationship owner and whether execution rate has been received or not (for a standard opportunity type); the execution rate-links, the execution modes and the Page 12 of 22

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

  

execution mode related data capture can be captured later at enrichment; it must also be possible to capture the party agreement, sales-relationship owner, the execution mode, the data associated with the execution mode and enter the execution rate links later at enrichment (please see the use case for the details) System will continue to allow users to save the ORF in draft status and later edit, submit them in line with the current system behaviour System will also give provision to the user to generate PDFs of the ORF and the associated Give-Up agreement System will change the display behavior on addition of existing contacts or new contacts: the contact types of trader and customer will be made available when creating new opportunities, but system must provide the provision of looking for existing contacts associated previously as a trader, but in the current ORF the trader has a customer role System will make use of the contacts when emailing marketers and live notifications, the main contact will be the ‘’trader’’ contact in a four party agreement and the ‘’customer’ ‘contact in a three party agreement

3.2.1.6 Archaic Business and System Rules

    

Sales manager approver process is redundant NBC approval/NBC exempt process is redundant The existing party structure of Parent, Legal entity and Investment manager is redundant Legal entity and associated product adoption is redundant Opportunity type will be a classification at the Give Up agreement level and not at the ORF level

3.2.1.7 Trigger User selects the option to create a new opportunity: y y selecting Create ORF, Give-Up agreement, New DB Execution Only 3.2.1.8 Frequency of use High 3.2.1.8.1 Create Opportunity Request for Execution only Give-up agreement(s) Step 1. 2. 3. 4. Description User selects the option to create a new opportunity, Give-up, DB Execution only on LD business line System shows the opportunity basic details and sales related information User d enters information associated with sales person, desk head and selects the provision to add Give-up agreement System provides the provision to construct a three party or four party give-up agreement, defaults the status to ‘’In progress’’ on the Give-up agreement, displays option to choose the opportunity type as well as the ability to choose the relationship owner, more than one sales-relationship owner from a pre-defined list of sales persons; the first Give-up agreement will carry the same value as the sales person entered at the ORF level with a provision to add more than one salesPage 13 of 22

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

Step

Description relationship owner ; system also defaults the Give-Up agreement status as ‘’In progress status’’

5.

User chooses ‘’standard’’ as the opportunity type on the Give-Up agreement, enters the relationship owner and completes the Give-Up agreement as a three or four party System displays provision to record whether execution rate has been received via choice of ‘’yes’’ and ‘’no’’, defaulting the execution rate received as ‘’Yes’’ after determining the Give-Up to be of type ‘’Standard’’; System provides option to capture modes of execution (Voice, DMA); In addition system checks whether this is the first Give-Up agreement of an ORF, determining that it is the first give-up agreement system retains the default choice of Yes and allows the user to proceed User enters the date the execution rate has been received, selects execution mode DMA

6.

7.

8.

System displays provision to capture DMA related data and displays provision for the user to enter the upload-link of the execution rate (the document will not be uploaded, but the hyper link will be entered by the user, stored for retrieval and update later) User enters the DMA data and also the hyperlink of the execution rate on the DMA System provides ‘’Add’ (+) button next to the Give-up agreement to add an additional Give-Up agreement System provides a provision to use existing contact types of trader or customer or broker, add trader, customer, broker or add a new contact totally. A contact type of trader in a four party agreement can end up as a customer in a third party agreement and vice versa User adds the contact and saves the opportunity as a draft and system generates ORF id User exits the use case.

9. 10. 11.

12. 13.

3.2.1.8.2

Alternative Scenarios Alternate scenario 1- User submits the ORF for approval- From step 12 of MSS or step 3 of

alternate scenario
Step 1. 2.

Description User selects the option to submit the ORF for approval. System validates the ORF values as per business rules and finds that all the values entered/selected are valid. Page 14 of 22
Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

3. 4.

System saves the updated values. System captures the audit trail for the ORF with date-time stamp of submission and user who submitted it.

Alternate scenario 2- Execution rates have not been received and user chooses DMA-

From step 6 of MSS
Step 1. 2.

Description User chooses the option that the execution rates have not been received yet for a standard agreement. System provides option to capture modes of execution (Voice, DMA), disables provision to enter the date the date the execution rate has been received as well as disables the fields that capture the hyperlinks of rates-upload on Voice, DMA as well as Voice & DMA User chooses DMA as the execution mode System provides provision to capture DMA related information Use case proceeds from step 10 of the main use case

3. 4. 5.

Alternate scenario 3- Execution rates have not been received and user chooses Voice- From step 6 of MSS Step 1. 2. Description User chooses the option that the execution rates have not been received yet for a standard agreement (chooses ‘’no’’ on execution rates received) System provides option to capture modes of execution (Voice, DMA), disables provision to enter the date the date the execution rate has been received as well as disables the fields that capture the hyperlinks of rates-upload on Voice, DMA as well as Voice & DMA User chooses Voice as the execution mode System provides provision to capture Voice related information and user enters Voice related information Use case proceeds from step 10 of the main use case

3. 4. 5.

Alternate scenario 4- Execution rates have not been received and user chooses Voice & DMA- From step 6 of MSS Step 1. Description User chooses the option that the execution rates have not been received yet for a Page 15 of 22
Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

standard agreement (chooses ‘’no’’ on execution rates received) 2. System provides option to capture modes of execution (Voice, DMA), disables provision to enter the date the date the execution rate has been received as well as disables the fields that capture the hyperlinks of rates-upload on Voice, DMA as well as Voice & DMA User chooses Voice as the execution mode System provides provision to capture Voice related information and user enters voice related information User chooses DMA as the execution mode System provides provision to capture DMA related information and user enters voice related information (user can perform step 3, 4 first then step 5, 6 or step 5, 6 first, then steps 3,4) Use case proceeds from step 10 of the main use case

3. 4. 5. 6.

7.

Alternate scenario 5- Execution rates have been received and user chooses Voice instead of DMA- From step 7 of MSS Step 1. 2. Description User enters the date the execution rate has been received, selects execution mode Voice System displays provision to capture Voice related data and displays provision for the user to enter the upload-link of the execution rate (the document will not be uploaded, but the hyper link will be entered by the user, stored for retrieval and update later) User enters the voice data and also the hyperlink of the execution rate on the Voice Use case proceeds from step 10 of the main use case

3. 4.

Alternate scenario 6- Execution rates have been received and user chooses Voice in addition to DMA- From step 9 of MSS Step 1. 2. Description User selects execution mode Voice in addition to DMA System displays provision to capture Voice related data and displays provision for the user to enter the upload-link of the execution rate corresponding to Voice(the document will not be uploaded, but the hyper link will be entered by the user, stored for retrieval and update later) as well as provision to enter hyperlink of rate common to both Voice and DMA Page 16 of 22

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

3. 4.

User enters the voice data and also the hyperlink of the execution rate on the Voice Use case proceeds from step 10 of the main use case

Alternate scenario 7 - Execution rates have been received and user chooses Voice in addition to DMA as well as wants to use a rate common to Voice & DMA - From step 2

of alternate scenario 6
Step 1. 2.

Description User selects execution mode Voice in addition to DMA System displays provision to capture Voice related data and displays provision for the user to enter the upload-link of the execution rate corresponding to Voice(the document will not be uploaded, but the hyper link will be entered by the user, stored for retrieval and update later) as well as a provision to capture hyperlink that covers execution rate of Voice and DMA together User enters the voice data User enters the rate upload-hyperlink common to both on the field provided by the system to enter common rate related link System provides a provision to use existing contact types of trader or customer, add trader, customer or add a new contact totally. User tries to save ORF as draft System validates and finds entry of upload-rates hyperlink on both DMA and DMA plus Voice and displays error message System provides ‘’Add’ (+) button next to the Give-up agreement to add an additional Give-Up agreement User removes hyper-link entered on DMA and again submits as draft System generates ORF id

3. 4. 5. 6. 7. 8. 9. 10.

Alternate scenario 8- User chooses the opportunity type to be LME (London metal exchange)

or EFP (exchange for physical) on the Give-Up agreement From step 5 of MSS
Step 1. 2. Description

User chooses ‘’LME’’ or ‘’EFP’’ as the opportunity type on the Give-Up agreement and the relationship owner System disables execution rates received options (‘’Yes’ ‘and ‘’No’’ buttons) and enables ‘’NA’’ Page 17 of 22
Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

3.

System provides a provision to use existing contact types of trader or customer, add trader, customer or add a new contact totally (the system does not display execution modes, execution rates and the data capture in the execution mode) User adds the contact and saves the opportunity as a draft User exits the use case.

4. 5.

Alternate scenario 9- User chooses to add multiple Give-ups and selects option to add

another Give-Up agreement From step 10 of MSS
Step 1. 2. 3. 4.

Description System displays an Add (+) icon next to the Give-Up agreement User selects (+) System displays provision to start the next Give-Up agreement System provides the provision to construct a three party or four party give-up agreement, defaults the status to ‘’In progress’’ on the Give-up agreement, displays option to choose the opportunity type as well as the ability to choose the relationship owner from a pre-defined list of sales persons as this is the second Give-up agreement. system also defaults the Give-Up agreement status as ‘’In progress status’’ User chooses ‘’standard’’ as the opportunity type on the Give-Up agreement, enters the relationship owner and completes the Give-Up agreement as a three or four party System determines this Give-Up agreement is not the first one and is also of type ‘’standard’’ and in addition to a provision to record whether execution rate has been received via choice of ‘’yes’’ and ‘’no’’, system also provides provision to clone data from a standard Give-Up agreement that was input earlier by providing ‘’same as’’ - a drop down check box for the user to go clone the data from. System also defaults the execution rate received as ‘’Yes’’, provides option to capture modes of execution (Voice, DMA) User chooses the source cloning Give-Up agreement from the same ORF System clones the following information: Execution modes, data capture associated with the execution modes as well as the links used on execution rates System proceeds from step 10 of the main success scenario

5.

6.

7. 8. 9.

Alternate scenario 10- from Alternative scenario 9 step 5 1. User chooses ‘’EFP’’ or ‘’LME’’ as the opportunity type on the Give-Up agreement, enters the relationship owner and completes the Give-Up agreement as a three or Page 18 of 22

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

For internal use onlyFor internal use onlyFor internal use only

four party 2. System determines this Give-Up agreement is not the first one and is also not of type ‘’standard’’, so disenables execution rates received choices and enables ‘’NA’’ against the execution rates; system will not display the cloning provision as the Give-Up agreement is standard Give-Up agreement System proceeds from step 10 of the main success scenario

3.

Alternate scenario 11- from Alternative scenario 2 & 3 - step 3 1. System proceeds from step 10 of the main case confirming that the user has entered the parties of the agreement, the opportunity type, the sales-relationship owner Use case ends

2.

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

Page 19 of 22

For internal use onlyFor internal use onlyFor internal use only

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

Page 20 of 22

For internal use onlyFor internal use onlyFor internal use only

3.2.1.9 ORF Process structure view

Execution only ORF

Field Code Changed

1 Opportunity request

1..n Desk head
n

Reports to

Salesrelationship owner

Give-up agreement manages
m n

Contacts

Trader

Customer

EFP

LME

Standard Party

0..2(always 0 for EFP and LME)
Execution Mode

Voice & DMA

Voice Voice Data

DMA

0..1 Trader

1 Customer

1 Execution Broker

1

Execution Rate

Clearing Broker

DMA Data

Disclosed Customer Name

Default customer name

3.2.1.10 ORF Screen mock-up for Execution only

This original mock-up has been prepared by the business: Changes have been carried out as per the business rules, system rules, Use case and ORF process structure view outlined above, but unfortunately the mock-up does not reflect all changes, all business rules and system rules discussed. ; Also there must be a relationship owner field on every give up agreement, the list will be the same as sales person list, though the first Give-Up agreement will carry the owner name same as sales person. It is strongly recommended that the development
team use this mock-up a guide to understand all the rules, data structure and the behaviour documented above; Functional specifications Part I Page 21 of 22
Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

For internal use onlyFor internal use onlyFor internal use only

Using the mock-up alone and developing it will result in missing out key things; this is the reason the mock-up has been provided at the end and not in the beginning.

Only worksheet ‘’Create ORF for Execution is applicable under this section’’
Field Code Changed

3.2.1.11 Data capture sheet for Execution DMA & Voice

Formatted: Font: (Default) Tahoma, 10 pt Formatted: Font: (Default) Tahoma, 10 pt

Functional specifications Part I

Page 22 of 22

For internal use onlyFor internal use onlyFor internal use only

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->