Background

These guidelines have been approved by the Use Cases Working Group in August of 2019.  They started as an 'opinionated' discussion document, followed by discussions, and then votes on what Use Cases (UC) the Working Group (WG) should accept. Having a set of agreed guidelines will 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 as 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, the WG should 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 the 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'.

Please continue to engage with these Guidelines 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, there are two separate questions to answer:

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

WG decisions to not proceed with a use case should include a reason which describes if the rejection is because of validity or usefulness. Rejected Use Cases will 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 a real UC for FDC3 Personas?
• Does it apply to areas of concern for FDC3?
• Is it unique from other UCs?

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

• A User running applications on a desktop
• A Technologist enabling a User to run applications (see this this document for further details on the Technologist persona)

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?

In general a useful use case is one that will help solve interoperability issues found among members of FDC3 and will therefore, by definition, be a test case for the specifications being defined in other working groups.

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 architectures would work and these can be particularly important Use Cases.