Background

This is an 'opinionated' discussion document that is presented to allow a discussion on what Use Cases (UC) the Working Group (WG) should accept. Having a set of agreed guidelines, should provide two benefits :

• improve consistency in reviewing the use cases to accept in FDC3.
• The act of producing these guidelines should allow certain recurring points to be discussed and agreed once, rather than raising them in each UC discussion!

The Guidelines when adopted are not a final arbiter of which Use Cases are valid, that should always be the responsibility of the WG responding to each Use Case. However, where these Guidelines are not followed, it would be good if the WG provide a comment to indicate which guidelines are being relaxed and why that decision was taken to help promote consistency.

It is important to note that the goal of consistency in decisions should not be used to prevent changes to the way the WG operates, it would however be good to update these guidelines as WG practice changes.

Accepted Use Cases will be shared with the relevant Working Groups. There is no requirement that any of the other Working Groups will ‘work’ on the Use Case,For example a WG might :

• reject a UC
• add the UC to their backlog
• indicate that the UC is already supported and show how the specification is used to deliver the UC.

But it is expected that the WG's will at least update the UC WG Confluence page with their decision and a brief 'reason'.

Initially please engage with this proposal either by comments or by creating an alternative set of guidelines and referencing them in a comment on this page.

The Guidelines

In considering a use case, this guidelines proposes that there are two separate questions to answer:

• Is the Use Case Valid ?
• If it is valid, is it a Useful ?.

WG group decisions to not proceed with a use case, should include a reason which should describe if the rejection is because of validity or usefulness. Rejected Use Cases should in general be kept on a Confluence page with their reject reason as a guide for others.

The following are points to consider in answer the two questions.

Is this a Valid Use Case?.

In summary the criteria are :

• Is it real UC for FDC3 participants?
• Does it apply to areas of concern for FDC3?

FDC3 Participant

Within this document an FDC3 Participant is defined as someone working with :

• A Member of the FDC3
• Financial industry firm.
  
  
• Product Vendor supplying end-user Platforms or Applications to the Financial Industry.
  Here I am thinking of companies like TR and ChartIQ.
  Their applications will typically be run at multiple companies, all of whom are running the same code. 
  
  
• Platform Vendor supplying products or services to developers producing end-user Products/Applications.
  Here I am thinking of companies like OpenFin, Glue42 and Plexus (even though DB also provide end-user applications).
  These products are often not visible to the User but they can are used to make the production of FDC3 compliant applications easier.
  

Valid Persona are used to introduce a use case, typically using the words 'As a <persona> ...'. Valid Persona for FDC3 UC's:

• A User running applications on a Windows desktop
• In-House Developers and Architects producing in-house applications the users run.
  The people are often working in-house either as employees or consultants.
  A key differentiator is that their applications are typically only used in one company
• Product Developers and Architects working in a Vendor to design, implement, install and configure the Platform or Application for a User.
• Vendor Developers and Architects working in a Vendor to desing and implement the products and services that can be used by In-house Developers and/or Product Developers. 

FDC3 Areas of concern

The FDC3 Areas of concern are :

• ‘to create standards for desktop application interoperability in the financial industry.’
• Help these standards to be used to help create applications that implement this interoperability by publicising the standards and by offerings products and services that help with the FDC3 application delivery..

Is this a Useful Use Case?.

A use case may be valid, but the Working Group may choose to reject it. This section contains some Guidelines on factors to consider in accepting or rejecting a valid Use Case, by addressing the question; 'is the UC Useful?'.

In general a useful use case is one that will help one or more of the other FDC3 Working Groups make decisions on the scope or details of their services and/or provide a useful test for their specifications. 

Some specific questions to consider are :

• Does it apply broadly to multiple users, firms and/or vendors?
• Will the Use Case be relevant to any of the current FDC3 Working Groups ?
  If not the Use Case will typically be rejected but could in exceptional cases lead to the creation of a new working group.
• Will the Use Case be relevant to multiple firms.?
  If a UC is very specific to a particular company it should either be rejected or restated in a more general form.
• Will the Use Case be relevant to multiple to FDC3 compliant applications?
  These may be vendor and/or in-house applications. If a UC is very specific to a particular Application, it should either be rejected or restated in a more general form.
• Does the Use Case help in selecting between various possible architectures or strategies?
  Whilst it is important that the Use Cases do not define an implementation or technology, some Use Cases have a clear impact on what architecture's would work and these can be particularly important Use Cases.