![]() |
Page History
Wiki Markup |
---|
{scrollbar:icons=false}
h1. { |
Page info | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Panel | ||||
---|---|---|---|---|
| ||||
|
Federated terminology repository
Use Case Number | FTSSD1 |
---|---|
Brief Description | This use case describes the usage of a federated terminology repository on the Grid |
Actor(s) for this particular use case | Curator |
Pre-condition |
|
Post condition | User is able to fetch concepts of his/her interests if they are available at any public instance of the federated terminology repository |
Steps to take |
|
Alternate Flow | None |
Priority | High |
Associated Links |
|
Fit criterion/Acceptance Criterion |
|
Metadata repository
Use Case Number | FMRSD2 |
---|---|
Brief Description | This use case describes the registration of metadata on federated metadata registry |
Actor(s) for this particular use case | Curator |
Pre-condition | Fully annotated metadata has been created |
Post condition | User is able to view the data that he has registered on the repository |
Steps to take |
|
Alternate Flow | None |
Priority | High |
Associated Links | |
Fit criterion/Acceptance Criterion |
|
Federated metadata browser
Use Case Number | FMBSD3 |
---|---|
Brief Description | This use case describes the querying of metadata on federated metadata registry using a federated metadata browser |
Actor(s) for this particular use case | Information modeler |
Pre-condition | Multiple metadata repositories with common API are available for the browser to browse |
Post condition | User is able to fetch metadata of his/her interests if they are available at any instance of the federated metadata repository |
Steps to take |
|
Alternate Flow | None |
Priority | High |
Associated Links |
|
Fit criterion/Acceptance Criterion | User can browse through multiple metadata repositories and choose the best available option |
Use Case - Descriptive Name
Use Case Number | |
---|---|
Brief Description |
|
Actor(s) for this particular use case |
|
Pre-condition |
|
Post condition |
|
Steps to take | 1. |
Alternate Flow |
|
Priority |
|
Associated Links |
|
Fit criterion/Acceptance Criterion |
|
Use Case - Descriptive Name
Use Case Number | n.n |
---|---|
Brief Description |
|
Actor(s) for this particular use case |
|
Pre-condition |
|
Post condition |
|
Steps to take | 1. |
Alternate Flow |
|
Priority |
|
Associated Links |
|
Fit criterion/Acceptance Criterion |
|
Wiki Markup |
---|
:title}
{anchor:ContentsofthisPage}{panel:title=Contents of this Page}
{toc:minLevel=2}
{panel}
h2. Federated terminology repository
|| *Use Case Number* \\
The author-assigned number to refer to each specific use case. The format of this number is _<SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>_, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc. \\ | FTSSD1 |
|| *Brief Description* | This use case describes the usage of a federated terminology repository on the Grid |
|| *Actor(s)* for this particular use case | Curator |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | # There is federated terminology browser available
# User has access to the browser |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | User is able to fetch concepts of his/her interests if they are available at any public instance of the federated terminology repository |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # User invokes the browser
# Browser Queries on multiple public instances of the terminology repositories
# Browser returns with concept information from whatever instances it is available at |
|| *Alternate Flow* \\
Things which would prevent the normal flow of the use case \\ | None |
|| *Priority* \\
The priority of implementing the use case: *High, Medium or Low* \\ | High |
|| *Associated Links* \\
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case. \\ | |
|| *Fit criterion/Acceptance Criterion* \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | \\
User can browse through multiple terminology repositories. |
h2. Metadata repository
|| *Use Case Number* \\
The author-assigned number to refer to each specific use case. The format of this number is _<SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>_, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc. | FMRSD2 |
|| *Brief Description* | This use case describes the registration of metadata on federated metadata registry |
|| *Actor(s)* for this particular use case | Curator |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | Fully annotated metadata has been created |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | User is able to view the data that he has registered on the repository |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # Actor creates the metadata
# Invokes the metadata registry service
# Metadata is registered on the local repository |
|| *Alternate Flow* \\
Things which would prevent the normal flow of the use case \\ | None |
|| *Priority* \\
The priority of implementing the use case: *High, Medium or Low* \\ | High |
|| *Associated Links* \\
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case. \\ | \\ |
|| *Fit criterion/Acceptance Criterion* \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | # User is able to view the data that he has registered on the repository
# The local repository should expose a common API to allow federation |
h2. Federated metadata browser
|| *Use Case Number* \\
The author-assigned number to refer to each specific use case. The format of this number is _<SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>_, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc. | FMBSD3 |
|| *Brief Description* | This use case describes the querying of metadata on federated metadata registry using a federated metadata browser |
|| *Actor(s)* for this particular use case | Information modeler |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | Multiple metadata repositories with common API are available for the browser to browse |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | User is able to fetch metadata of his/her interests if they are available at any instance of the federated metadata repository |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # User invokes the browser
# Queries for metadata of interest
# Browser returns with metadata information from whatever instances it is available at |
|| *Alternate Flow* \\
Things which would prevent the normal flow of the use case \\ | None |
|| *Priority* \\
The priority of implementing the use case: *High, Medium or Low* \\ | High |
|| *Associated Links* \\
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case. \\ | |
|| *Fit criterion/Acceptance Criterion* \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | User can browse through multiple metadata repositories and choose the best available option |
h2. Use Case - Descriptive Name
|| *Use Case Number* \\
The author-assigned number to refer to each specific use case. The format of this number is _<SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>_, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc. | \\ |
|| *Brief Description* | |
|| *Actor(s)* for this particular use case | |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | 1. \\
2. \\ |
|| *Alternate Flow* \\
Things which would prevent the normal flow of the use case \\ | |
|| *Priority* \\
The priority of implementing the use case: *High, Medium or Low* \\ | |
|| *Associated Links* \\
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case. \\ | |
|| *Fit criterion/Acceptance Criterion* \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | \\
1. \\
2... |
h2. Use Case - Descriptive Name
|| *Use Case Number* \\
The author-assigned number to refer to each specific use case. The format of this number is _<SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>_, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc. | n.n |
|| *Brief Description* | |
|| *Actor(s)* for this particular use case | |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | 1. \\
2. \\ |
|| *Alternate Flow* \\
Things which would prevent the normal flow of the use case \\ | |
|| *Priority* \\
The priority of implementing the use case: *High, Medium or Low* \\ | |
|| *Associated Links* \\
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case. \\ | |
|| *Fit criterion/Acceptance Criterion* \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | \\
1. \\
2... |
\\
{scrollbar:icons=false} |