Difference between revisions of "WP11: API Cases Identification Report Template"
(Created page with "== API Case Report Template ==") |
(→API Case Report Template) |
||
| Line 1: | Line 1: | ||
| − | == API Case | + | == Label == |
| + | A distinctive label in the form of a single line title is assigned to each case for an API of the functional area. Wiki URL and track tickets have to be bound with this title. The case can obtain also an ID and then can be bound to the Track Ticket when the case comes into implementation. | ||
| + | |||
| + | == Objective == | ||
| + | A short description of the objective of the API case. | ||
| + | |||
| + | == Area Working Group == | ||
| + | The working group that deals with the case. | ||
| + | |||
| + | |||
| + | == Detailed Description == | ||
| + | This section contains the detailed verbal description of the API case of the functional area and is expected to be quite extended when complete. | ||
| + | |||
| + | The following topics should be covered by the description of a case: | ||
| + | * Verbal description that refers to details of resources interactions. This should contain: | ||
| + | ** Resources Analysis | ||
| + | *** Definition of the flows of resources (data, facilities, etc.) that fall under the corresponding infrastructure layer | ||
| + | *** Examination of the significance of the resources involved and the multiplicity of facets they expose | ||
| + | ** Options and Needs Analysis | ||
| + | *** Examination of the overall infrastructure's capabilities and the requirements for their exploitation by other resources | ||
| + | *** Designation of perceptions of flows' needs and opportunities | ||
| + | *** Definition of the given options | ||
| + | ** API Integration | ||
| + | Analysis of operations that will promote integration and interoperability based on previous designation of needs and opportunities | ||
| + | * Specifications' descriptions | ||
| + | Description of specifications with a justification for their placement in the case | ||
| + | ** Optional abstract diagrams of interactions (flow/control) | ||
| + | Indicatively diagrams should fall under the Behavior or Interaction classification of UML diagrams. | ||
| + | |||
| + | == Case evaluation == | ||
| + | A divided section of costs and benefits of the designed case, for assisting the evaluation of the case. The following sections should be identified. | ||
| + | |||
| + | === Case benefits === | ||
| + | All the benefits brought to the ecosystem by the case have to be enumerated and if possible quantified: | ||
| + | * Security of the case: i.e. how safe the realization of a case is. (If a case is risky, then this attribute goes into the cons) | ||
| + | * gCube issues addressed | ||
| + | * iMarine project opportunities opened | ||
| + | * New resources brought in either direction | ||
| + | * Case reuse (beyond even interoperability) | ||
| + | * Case alignment with the objective of the project, the nature of the systems, and other cases | ||
| + | |||
| + | == Case implications and risks == | ||
| + | There are several reasons for classifying a case as risky: | ||
| + | * standards are missing | ||
| + | * the effort is not clear | ||
| + | * too many dependencies identified | ||
| + | * the expected expoitation of the case is not secure | ||
| + | etc. | ||
| + | |||
| + | All these have to be identified as part of the case evaluation. | ||
| + | |||
| + | == Implementation cost and time line == | ||
| + | The estimation of the overall case implementation cost and timeline is quite valuable for the evaluation of a case and its promotion to follow an implementation path and as such it has to be provided. | ||
| + | |||
| + | == Protocols/Specifications Sum-up == | ||
| + | The reference of the protocols / specifications involved in the case can be enriched with flags labeling them as: | ||
| + | * required/desired/optional/speculated | ||
| + | * existing/extension/new | ||
Revision as of 11:05, 23 January 2012
Label
A distinctive label in the form of a single line title is assigned to each case for an API of the functional area. Wiki URL and track tickets have to be bound with this title. The case can obtain also an ID and then can be bound to the Track Ticket when the case comes into implementation.
Objective
A short description of the objective of the API case.
Area Working Group
The working group that deals with the case.
Detailed Description
This section contains the detailed verbal description of the API case of the functional area and is expected to be quite extended when complete.
The following topics should be covered by the description of a case:
- Verbal description that refers to details of resources interactions. This should contain:
- Resources Analysis
- Definition of the flows of resources (data, facilities, etc.) that fall under the corresponding infrastructure layer
- Examination of the significance of the resources involved and the multiplicity of facets they expose
- Options and Needs Analysis
- Examination of the overall infrastructure's capabilities and the requirements for their exploitation by other resources
- Designation of perceptions of flows' needs and opportunities
- Definition of the given options
- API Integration
- Resources Analysis
Analysis of operations that will promote integration and interoperability based on previous designation of needs and opportunities
- Specifications' descriptions
Description of specifications with a justification for their placement in the case
- Optional abstract diagrams of interactions (flow/control)
Indicatively diagrams should fall under the Behavior or Interaction classification of UML diagrams.
Case evaluation
A divided section of costs and benefits of the designed case, for assisting the evaluation of the case. The following sections should be identified.
Case benefits
All the benefits brought to the ecosystem by the case have to be enumerated and if possible quantified:
- Security of the case: i.e. how safe the realization of a case is. (If a case is risky, then this attribute goes into the cons)
- gCube issues addressed
- iMarine project opportunities opened
- New resources brought in either direction
- Case reuse (beyond even interoperability)
- Case alignment with the objective of the project, the nature of the systems, and other cases
Case implications and risks
There are several reasons for classifying a case as risky:
- standards are missing
- the effort is not clear
- too many dependencies identified
- the expected expoitation of the case is not secure
etc.
All these have to be identified as part of the case evaluation.
Implementation cost and time line
The estimation of the overall case implementation cost and timeline is quite valuable for the evaluation of a case and its promotion to follow an implementation path and as such it has to be provided.
Protocols/Specifications Sum-up
The reference of the protocols / specifications involved in the case can be enriched with flags labeling them as:
- required/desired/optional/speculated
- existing/extension/new
