Difference between revisions of "PubMan Func Spec Quality Assurance"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 219: Line 219:
===Flow of Events===
===Flow of Events===
*1. The user chooses to accept and authorize the item.
*1. The user chooses to accept and authorize the item.
*2. Include use case UC_PM_SM_09 validate item for validation point "accept".
*2. Include use case [[PubMan_Func_Spec_Submission#UC_PM_SM_09_validate_item|UC_PM_SM_09 validate item]] for validation point "accept".
*3. The system checks the validation report status.
*3. The system checks the validation report status.
**a. The validation report status is valid.
**a. The validation report status is valid.
Line 227: Line 227:
*6. The user confirms the input.
*6. The user confirms the input.
*7. The system displays a success message (MSG_PM_QA_10). The use case ends successfully.
*7. The system displays a success message (MSG_PM_QA_10). The use case ends successfully.
===Post-Conditions / Results===
===Post-Conditions / Results===
*None
*None

Revision as of 09:48, 22 January 2008

PubMan Functional Specification

View · Browse
Full Submission · Easy Submission
Import · Export
Quality Assurance · Search
Collaboration · Copyright
Collection Administration
Organizational Unit Management
User Management
Feeding local webpages
History of affiliations


edit

UC_PM_QA_01 confirm pre-check item[edit]

The user selects the last version of an item for a formal pre-check. Depending on the publication or modification workflow the item has to be checked by one Metadata Editor.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:to be defined (depends on workflow engine and GUI concept workspace)

Triggers[edit]

  • The user wants to do a formal pre-check of an item.

Actors[edit]

  • Metadata Editor

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state “submitted”.

Flow of Events[edit]

  • 1. The user chooses to pre-check the item.
  • 2. Include use case UC_PM_SM_09 validate item for validation point "submit".
  • 3. The system checks the validation report status.
    • a. The validation report status is valid.
    • b. The validation report status is invalid. The selected item is unaffected. The system displays an error message (MSG_PM_QA_01). The use case ends without success.
  • 4. The system prompts for a comment.
  • 5. (Optionally) The user enters a comment.
  • 6. The user confirms the input.
  • 7. The system displays a success message (MSG_PM_QA_02). The use case ends successfully.

Post-Conditions / Results[edit]

  • None

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_01_confirm_pre-check_item

UC_PM_QA_03 accept item[edit]

The user accepts the last item version because the formal quality of the item is good.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R3

Triggers[edit]

  • The user wants to accept an item.

Actors[edit]

  • Moderator

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state “submitted”.

Flow of Events[edit]

  • 1. The user chooses to accept the item.
  • 2. Include use case UC_PM_SM_09 validate item for validation point "accept".
  • 3. The system checks the validation report status.
    • a. The validation report status is valid.
    • b. The validation report status is invalid. The selected item is unaffected. The system displays an error message (MSG_PM_QA_03). The use case ends without success.
  • 4. The system prompts for a comment.
  • 5. (Optionally) The user enters a comment for the check.
  • 6. The user confirms the input.
  • 7. The system displays a success message (MSG_PM_QA_04). The use case ends successfully.

Post-Conditions / Results[edit]

  • None

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_03_accept_item

UC_PM_QA_04 send item back for rework[edit]

The user is not satisfied with the item version data and therefore sends the item version back for rework to the Depositor.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:to be defined (depends on workflow engine)

Triggers[edit]

  • The user wants to send an item back for rework.

Actors[edit]

  • Metadata Editor
  • Moderator
  • Authority

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state “submitted”.

Flow of Events[edit]

  • 1. The user chooses to send the item back for rework.
  • 2. The system prompts for a comment.
  • 3. (Optionally) The user specifies a comment.
  • 4. The user confirms the input.
  • 5. The system changes the status of the item version to “in rework” and displays a success message (MSG_PM_QA_05). The use case ends successfully.

Post-Conditions / Results[edit]

  • The item version is in state “in rework”.

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_04_send_item_back_for_rework

UC_PM_QA_06 authorize item[edit]

The user authorizes the last item version because the scientific quality of the item is good.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:to be defined (depends on workflow engine and GUI concept workspace)

Triggers[edit]

  • The user wants to authorize an item.

Actors[edit]

  • Authority

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state “submitted”.

Flow of Events[edit]

  • 1. The user chooses to authorize the item.
  • 2. The system prompts for a comment.
  • 3. (Optionally) The user enters a comment for the check.
  • 4. The user confirms the input.
  • 5. The system displays a success message (MSG_PM_QA_06). The use case ends successfully.

Post-Conditions / Results[edit]

  • None

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_06_authorize_item

UC_PM_QA_07 send item back for formal check[edit]

The user is not satisfied with the quality of the metadata of the last item version and therefore sends the item version back for formal check to the Moderator.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:to be defined (depends on workflow engine and GUI concept workspace)

Triggers[edit]

  • The user wants to send an item back for formal check.

Actors[edit]

  • Authority

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state “submitted”.

Flow of Events[edit]

  • 1. The user chooses to send the item back for formal check.
  • 2. The system prompts for a comment.
  • 3. (Optionally) The user specifies a comment.
  • 4. The user confirms the input.
  • 5. The system stores the information and displays a success message (MSG_PM_QA_07). The use case ends successfully.

Post-Conditions / Results[edit]

  • None

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_07_send_item_back_for_formal_check

UC_PM_QA_08 release item[edit]

The system releases the last version of the item.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R3

Triggers[edit]

  • The last item version has to be released.

Actors[edit]

  • System

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state “submitted”.

Flow of Events[edit]

  • 1. The system requests a PID and assigns it to the item. For each file attached to the item the system requests a PID and assigns it to the file.
  • 2. The system sets the state of the item version to “released”.
  • 3. The system saves the data and displays a success message (MSG_PM_QA_08). The use case ends successfully.

Post-Conditions / Results[edit]

  • The item version is in state “released”.

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_08_release_item

UC_PM_QA_09 withdraw item[edit]

The owner of the item or the Local Administrator withdraws the item because the item should no longer be accessible via the IR.

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R1

Triggers[edit]

  • The user wants to withdraw an item.

Actors[edit]

  • Depositor
  • Local Administrator

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state “released”.
  • The user is the owner of the item or the Local Administrator.

Flow of Events[edit]

  • 1. The user chooses to withdraw the item.
  • 2. The system prompts for a reason for the withdrawal.
  • 3. The user enters a reason and confirms the withdrawal.
  • 4. The system changes the state of the item to “withdrawn” and stores the withdrawal comment. The system displays a success message (MSG_PM_QA_09). The use case ends successfully.

Post-Conditions / Results[edit]

  • The item is in state “withdrawn”.

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_09_withdraw_item

UC_PM_QA_10 accept and authorize item[edit]

The user accepts the last item version because the formal quality of the item is good. In addition the user decides that no further scientific check is required.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:to be defined(depends on workflow engine and GUI concept workspace)

Triggers[edit]

  • The user wants to accept and authorize an item.

Actors[edit]

  • Moderator

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state “submitted”.

Flow of Events[edit]

  • 1. The user chooses to accept and authorize the item.
  • 2. Include use case UC_PM_SM_09 validate item for validation point "accept".
  • 3. The system checks the validation report status.
    • a. The validation report status is valid.
    • b. The validation report status is invalid. The selected item is unaffected. The system displays an error message (MSG_PM_QA_03). The use case ends without success.
  • 4. The system prompts for a comment.
  • 5. (Optionally) The user enters a comment.
  • 6. The user confirms the input.
  • 7. The system displays a success message (MSG_PM_QA_10). The use case ends successfully.

Post-Conditions / Results[edit]

  • None

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_10_accept_and_authorize_item

UC_PM_QA_11 modify item[edit]

The user modifies an released item by providing additional data, correcting or deleting existing values. With this action he starts the modification workflow.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R3

Triggers[edit]

  • The user wants to modify an item.

Actors[edit]

  • Depositor
  • Further actors depending on the modification workflow of the item’s collection

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state “released”.

Flow of Events[edit]

  • 1. The user chooses to modify an item.
  • 2. The user has a role other than “Depositor”. The system creates a new item version with the status “submitted”. Include use case UC_PM_SM_02 edit item with the item as selected item and the validation point defined in the modification workflow of the item’s collection as selected validation point. The use case ends successfully.

Alternatives[edit]

  • 2a. The user has the role “Depositor”. The system creates a new item version with the status “pending”. Include use case UC_PM_SM_02 edit item with the item as selected item and the validation point “submit” as selected validation point. The use case ends successfully.

Post-Conditions / Results[edit]

  • The item is in state “pending” or “submitted”.
  • The item data is saved.

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_11_modify_item

UC_PM_QA_13 revert to last released version[edit]

Depending on the modification workflow the user is able to delete all item versions back to the last released version.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:to be defined

Triggers[edit]

  • The user wants to revert the item to the last released version.

Actors[edit]

  • Moderator
  • Metadata Editor

Pre-Conditions[edit]

  • One item is selected.
  • The item has at least one version in state “released”.
  • The last item version is in state “submitted”.

Flow of Events[edit]

  • 1. The user chooses to revert to the last released version.
  • 2. The system displays a list of the versions back to the last release and prompts the user to confirm and comment the deletion of the versions.
  • 3. (Optionally) The user enters a comment for the deletion of the item versions.
  • 4. The user confirms the deletion of the item versions.
  • 5. The system deletes the item versions back to the last released version and displays a success message (MSG_PM_QA_11). The use case ends successfully.

Post-Conditions / Results[edit]

  • All item versions after the last released version are deleted.

Discussion[edit]

Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_13_revert_to_last_released_version

Workflow[edit]

please see PubMan workflows

HTML Prototype[edit]

Prototype Quality Assurance