Serving the Quantitative Finance Community

 
User avatar
Cuchulainn
Posts: 20253
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

User stories

October 6th, 2011, 10:44 am

What is a user?. end-users who is the GUI app. FO quants. MV quants. MFE students. library builders. etc?Serious question.
Last edited by Cuchulainn on October 5th, 2011, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20253
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

User stories

October 6th, 2011, 11:10 am

QuoteAnd we even haven't touched the research quants that want to share new models in Matlab format.Might be able to get Matlab people on board. Stay tuned
 
User avatar
Cuchulainn
Posts: 20253
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

User stories

October 6th, 2011, 11:51 am

A follow-on remark: an interoperability SIG, user group ..C++ and . Matlab and MM, C# (via CLI). Excelother (not too many, avoid overstretch)
Last edited by Cuchulainn on October 5th, 2011, 10:00 pm, edited 1 time in total.
 
User avatar
rmax
Posts: 374
Joined: December 8th, 2005, 9:31 am

User stories

October 6th, 2011, 2:44 pm

I think there are three groups of users with a variety of use cases:1. Students. They will use the functions to help them understand how instruments work; understand how to code in C++ etc2. Non Quant financial professional: they will want to be able to do back of fag packet calculations in Excel; test numbers coming from quant systems to see if they are correct etc. In here I would include senior managers, ops, product control, IT etc3. Quant professionals: will want to plug and play modules, build their own functions etcIMHO I think 1 & 2 are easy to hit. Number 3 is going to be more difficult because of the wide range of responses:e.g.: Will it run on a grid?I want to use your Yield Curve builder, but change the interpolation pointsCan you complile it for OS2 I think it was renorm that defined the onion analogy, and I think the same will apply here.
 
User avatar
Cuchulainn
Posts: 20253
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

User stories

October 6th, 2011, 3:07 pm

QuoteIMHO I think 1 & 2 are easy to hit. Number 3 is going to be more difficult because of the wide range of responses:Then we need a wide/focused range of questions?With s/w you a) deliver/give it or b) show how to deliver it (give a fish/fishing rod analogy), or both.Quote want to use your Yield Curve builder, but change the interpolation pointsAndrea Germani and I have done this in C# (incuding multi-curve).
Last edited by Cuchulainn on October 5th, 2011, 10:00 pm, edited 1 time in total.
 
User avatar
quartz
Posts: 3
Joined: June 28th, 2005, 12:33 pm

User stories

October 9th, 2011, 10:05 am

QuoteOriginally posted by: rmaxI think there are three groups of users with a variety of use cases:1. Students. They will use the functions to help them understand how instruments work; understand how to code in C++ etc2. Non Quant financial professional: they will want to be able to do back of fag packet calculations in Excel; test numbers coming from quant systems to see if they are correct etc. In here I would include senior managers, ops, product control, IT etc3. Quant professionals: will want to plug and play modules, build their own functions etcWe should definitely also consider the structurer using a payoff language, kind of 2,5? Shall FpML et similia be supported?That's one of the (many) reasons why I fear that requirements&architecture/design will require a lot of brainstorming, those topics don't seem settled at all yet in the SW market. And, taking the ball from another thread: it'd be great if the project wasnt restricted to pricing&risk but could span the whole range till HFT, to unite different communities so that common modules can benefit from more manpower (e.g. online stats, portfolio optimization). What about the energy markets? Outrun what's needed there that is out of the scope of classical financial tools?
 
User avatar
Cuchulainn
Posts: 20253
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

User stories

October 9th, 2011, 11:13 am

QuoteThat's one of the (many) reasons why I fear that requirements&architecture/design will require a lot of brainstorming, those topics don't seem settled at all yet in the SW market. The 'software market' is very big. But I agree (partially) that these are skills that are not in great abundance in the community. In domains outside QF they are well advanced. Example CBD It's not a skill that you are going to learn in a weekend or two.Just focusing on libraries may not be sufficient, as we all know. More is needed.Unfortunately, C++ does not support interfaces/components, which could be a problem with system integration. The biggest risk imo is the scaleability.
Last edited by Cuchulainn on October 8th, 2011, 10:00 pm, edited 1 time in total.