Serving the Quantitative Finance Community

 
User avatar
rmax
Topic Author
Posts: 374
Joined: December 8th, 2005, 9:31 am

Functional Requirements

October 25th, 2011, 1:00 pm

Not sure that the http://www.wilmottwiki.com/wiki/index.p ... jectreally covers the requirements in the traditional sense. I have been through a variety of the posts and extracted the Functional Requirements. By Functional Requirements I mean things that users will interact with and use.I will write another post at some point which will detail he non-functional requirements (e.g. parallel processing etc).BR01 Expected UsersThere are four expected class of users:1. Students. The solution will enable students of either Quantative Finance, Finance or Technology to understand models and concepts through the project.2. Finance Professionals. The solution will enable the easy pricing/investigation of products and behaviors by coupling a variety of modules together to obtain a required output3. Quantative professionals. The solution will provide a framework for building new models and adapting elements of current models to save ?re-invention? of common tasks.4. Professional Solutions. A professional company can make use of the solution as required as long as it obeys the licenseBR02 Module interoperabilityAll modules can be configured as required to give an output in-line with the use cases in BR02.e.g. 1. A student wishes to understand the pricing behaviour of an option and so inputs a number of parameters to obtain outputs as to how the valuation was obtained2. A Risk Professional needs to understand the price of an option that he does not at present have tools to price. He chooses the inputs and modules to use and price the option3. A Quantative professional is building a new model, and wishes to use the Monte Carlo framework already in place4. A Professional Solutions company has a better random number generator, and wishes to use the framework in this contextBR03 DatesCapability to cope with bank-holidays and multiple calendars.BR04 OutputsCapability to output a number of variables as required e.g.:- Valuation- Risk Sensitivities- Early exercise conditions- Model parameters (when calibrating)- Intermediate values for debugging and learningBR06 Market ConventionAll inputs will obey market conventionsBR07 User InterfaceThe calculation framework is independent of the GUI designed:1. Can be used through standard tools like Excel2. Can have other GUI added to use elements of the frameworkBR08 LicenseThe license is open source.BR09 ServiceThe solution will comply with the notions of a service to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.Please comment.
 
User avatar
Traden4Alpha
Posts: 3300
Joined: September 20th, 2002, 8:30 pm

Functional Requirements

October 25th, 2011, 3:24 pm

This look pretty good.One minor tweak to BR01 that I see two distinct student sub-populations: 1) students doing homework exercises such as for an MFE; 2) students doing original research such as for a PhD. The former need more rudimentary blackbox tools and the latter need to be able to: use the library; trace the code back to the theory; and add their own compatible extensions or modules.BR07 should probably include the full list of interfaces from the wiki page.Another requirement might relate to whether the library is like a set of wholly independent subroutines or whether the library includes code to manage some form of workspace or persistent store. That is, does the library include any glue for managing intermediate data objects, parameter sets, etc. Perhaps this is an element of the BR09 Service requirement? Or perhaps that task is best left to Excel, Matlab et al.****As a general aside, I often annotate any requirements document with some indicator of which requirements define the beta release or MVP (minimum viable product) and which might be part of release v1.0, v2.0, v 3.0, etc. It's too easy for a requirements document to become a kitchen-sink wishlist and define an unmanageable scope. Overlaying a roadmap helps focus effort on meeting the core of the requirements whilst also ensuring that the earliest version is not incompatible with what will be added later.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Functional Requirements

October 25th, 2011, 3:54 pm

This is a delineated description of software requirements from SEI Glossary of terms
Last edited by Cuchulainn on October 24th, 2011, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Functional Requirements

October 25th, 2011, 3:59 pm

QuoteOne minor tweak to BR01 that I see two distinct student sub-populations: 1) students doing homework exercises such as for an MFE; 2) students doing original research such as for a PhD. The former need more rudimentary blackbox tools and the latter need to be able to: use the library; trace the code back to the theory; and add their own compatible extensions or modules.This is a good classification. The s/w 'product' can be customised accordingly. MFE students have a heavy workload because they have to learn so much in a short period of time. For PhD it is more experimentation (as Paul mentioned) with models and what-if scenarios.
Last edited by Cuchulainn on October 24th, 2011, 10:00 pm, edited 1 time in total.
 
User avatar
rmax
Topic Author
Posts: 374
Joined: December 8th, 2005, 9:31 am

Functional Requirements

October 25th, 2011, 4:19 pm

Thanks for the input to date. I will not update until there are a few more comments reaped...
 
User avatar
daveangel
Posts: 5
Joined: October 20th, 2003, 4:05 pm

Functional Requirements

October 25th, 2011, 6:24 pm

anyone thinking about bringing in market data feeds ? for example if the tools are to be used as part of a portfolio management system. I may be going off tangent here but another issue that has bugged me in the past is how make "natural" instruments behave the same way as derived instruments. for instance, there is no theoretical price for an equity so this will need to come in as a market value. ditto for liquid futures contracts.
knowledge comes, wisdom lingers
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Functional Requirements

October 26th, 2011, 5:25 am

anyone thinking about bringing in market data feeds ? for example if the tools are to be used as part of a portfolio management system. for example, commercial data feeds?
Last edited by Cuchulainn on October 25th, 2011, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Functional Requirements

October 27th, 2011, 7:25 pm

Have the following inventories been done?StakeholderAny entity that directly or indirectly benefits from the introduction of the system. This group includes potential stakeholders.The types of stakeholder are: human/nonhuman, past/current/future, and direct/indirectActorA human or non-human entity that directly interacts with the system. Non-human actors can be hardware or other systems. We model the exchange of events and information between an actor and the system. Actors are not modelled, only their interactions.An actor participates in a scenario by sending messages to, and receiving messages from the system. Actors may also interact with each other.ViewpointA viewpoint represents an encapsulation of partial information about a system's requirements from a particular perspective. The categories of Viewpoint are Interactor, Stakeholder, and Domain.Viewpoints are intermediate-level techniques during the Requirements Elicitation phase.//It's nice to know what you are making, for whom, and why.In large complex environments so as here, this is essential. We should create categories initially (about 5-6). e.g. MFE/PhD students, Quant developers, Excel-based traders, market feeds (non-human), SEC and compliance, MO, model validation,...
Last edited by Cuchulainn on October 26th, 2011, 10:00 pm, edited 1 time in total.
 
User avatar
rmax
Topic Author
Posts: 374
Joined: December 8th, 2005, 9:31 am

Functional Requirements

October 27th, 2011, 7:32 pm

QuoteOriginally posted by: CuchulainnHave the following inventories been done?StakeholderAny entity that directly or indirectly benefits from the introduction of the system. This group includes potential stakeholders.The types of stakeholder are: human/nonhuman, past/current/future, and direct/indirectActorA human or non-human entity that directly interacts with the system. Non-human actors can be hardware or other systems. We model the exchange of events and information between an actor and the system. Actors are not modelled, only their interactions.An actor participates in a scenario by sending messages to, and receiving messages from the system. Actors may also interact with each other.Good point (again!). StakeholdersQuantTradingRiskProduct Control / IPVFO ITBO/FIN ITActorsTradersTrading SystemRiskRisk SystemSubledgerProduct Control/IPV Market Data SystemFirst draft only. Please add.
 
User avatar
rmax
Topic Author
Posts: 374
Joined: December 8th, 2005, 9:31 am

Functional Requirements

November 16th, 2011, 1:45 pm

Title RFC 001 Functional RequirementsVersion0.1ObjectiveThe objective of the Quantative Finance Code Library is to support the greater understanding of the methodologies used for pricing and valuation financial products and provide professionals and students a capability to value and price real-life products that are actively traded in the market using a comprehensive set of free methodologies and code.Stakeholders The following list of Stakeholders have been identifiedQuantative Analyst and Developers ? may have the need for a capability to price current portfolios, or require basic libraries to accelerate ?in-house? developmentsTrading ? may have the need for a capability to rapidly price a product that at present there no capability available to themRisk Management / Product Control / Independent Price Verification Divisions ? may have the need for a capability to understand product sets and wish to utilise an independent set of valuations to understand products and pricing methodologiesStudent ? Facilitate the understanding of products and the valuation techniques Graduate Student ? may need to the capability to trace code back to theory with the ability to add their own modulesFront Office and Back Office Technology ? may need to the capability to interface with QCFLProfessional Software Development or Consultancy Service Company ? may need the capability to accelerate their development, use the framework to test outputs of their bespoke products or build propriety binaries that integrates and extends into the QCFL framework.BR01 Ease of UsePrimarily the framework must be easy to use by users and stakeholder above. ?Easy to use? although is a non quantative measurement it implies the following principles:1. Keep It Simple Stupid (KISS), classes, functions, documentation will not be complex for complexity sake2. Function calls will be simple3. The framework will be documented ? nothing will be released as a core release without clear documentation being available4. Interfaces once migrated to the ?core? will be immutable. Other interfaces may be written, but the backward compatability must be maintained5. If the function/class/module is not Easy-to-Use it will either (a) not be included in the core release or (b) re-written from scratch observing point no. 4BR02 Module interoperabilityAll modules can be configured as required.e.g. 1. A student wishes to understand the pricing behaviour of an option and so inputs a number of parameters to obtain outputs as to how the valuation was obtained2. A Risk Professional needs to understand the price of an option that he does not at present have tools to price. He chooses the inputs and modules to use and price the option3. A Quantative professional is building a new model, and wishes to use the Monte Carlo framework already in place4. A Professional Solutions company has a better random number generator, and wishes to use the framework in this contextBR03 DatesCapability to cope with bank-holidays and multiple calendars.BR04 OutputsCapability to output a number of variables as required e.g.:- Valuation- Risk Sensitivities- Early exercise conditions- Model parameters (when calibrating)- Intermediate values for debugging and learningBR06 Market ConventionAll inputs will obey market conventionsBR07 User InterfaceThe calculation framework is independent of the GUI designed1. The framework can have any number of GUI attached2. At a minimum the following interfaces have been identified: - Excel- Matlab- R-project- Mathematica- PythonBR08 LicenseThe license is open source and will be free for use. However any commercial use will require the display of the QCFL logo, and name.BR09 ServiceThe solution will comply with the notions of a service to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.