...
...
...
...
...
...
...
...
Background
This is These guidelines have been approved by the Use Cases Working Group in August of 2019. They started as an 'opinionated' discussion document that is presented to allow a discussion , followed by discussions, and then votes on what Use Cases (UC) the Working Group (WG) should accept. Having a set of agreed guidelines , should 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 when 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, it would be good if 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 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, 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 Please continue to engage with this proposal 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, 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 describes if the rejection is because of validity or usefulness. Rejected Use Cases should in general 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 participantsPersonas?
- Does it apply to areas of concern for FDC3?
- Is it not a repeat of another UC?
FDC3 Participant
Within this document an FDC3 Participant is defined as someone working with :
...
- unique from other UCs?
Valid Personas are used to introduce a use case, typically using the words 'As a <persona> ...'. Valid Persona for FDC3 UC'sUCs are:
- 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
...
- 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?
...
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. 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 architecture's architectures would work and these can be particularly important Use Cases.
...