Difference between revisions of "PubMan Func Spec Quality Assurance"
Jump to navigation
Jump to search
| Line 6: | Line 6: | ||
*Schedule:'''R3''' | *Schedule:'''R3''' | ||
===Triggers=== | ===Triggers=== | ||
*The user wants to do a formal pre-check of an item. | |||
===Actors=== | ===Actors=== | ||
*Metadata Editor | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*One item is selected. | |||
''Comment Natasa: Last item version is selected?'' | ''Comment Natasa: Last item version is selected?'' | ||
*The last item version is in state “submitted”. | |||
===Flow of Events=== | ===Flow of Events=== | ||
| Line 39: | Line 39: | ||
===Post-Conditions / Results=== | ===Post-Conditions / Results=== | ||
*None | |||
==UC_PM_QA_03 accept item== | ==UC_PM_QA_03 accept item== | ||
| Line 47: | Line 47: | ||
*Schedule:'''R2''' | *Schedule:'''R2''' | ||
===Triggers=== | ===Triggers=== | ||
*The user wants to accept an item. | |||
===Actors=== | ===Actors=== | ||
*Moderator | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*One item is selected. | |||
*The last item version is in state “submitted”. | |||
===Flow of Events=== | ===Flow of Events=== | ||
| Line 68: | Line 68: | ||
*7. The system displays a success message (MSG_PM_QA_04). The use case ends successfully. | *7. The system displays a success message (MSG_PM_QA_04). The use case ends successfully. | ||
===Post-Conditions / Results=== | ===Post-Conditions / Results=== | ||
*None | |||
==UC_PM_QA_04 send item back for rework== | ==UC_PM_QA_04 send item back for rework== | ||
| Line 78: | Line 78: | ||
*Schedule:'''R3''' | *Schedule:'''R3''' | ||
===Triggers=== | ===Triggers=== | ||
*The user wants to send an item back for rework. | |||
''Comment Natasa: The last item version'' | ''Comment Natasa: The last item version'' | ||
===Actors=== | ===Actors=== | ||
*Metadata Editor | |||
*Moderator | |||
*Authority | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*One item is selected. | |||
''Comment Natasa: The last item version'' | ''Comment Natasa: The last item version'' | ||
*The last item version is in state “submitted”. | |||
===Flow of Events=== | ===Flow of Events=== | ||
| Line 102: | Line 102: | ||
*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. | *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=== | ===Post-Conditions / Results=== | ||
*The item version is in state “in rework”. | |||
==UC_PM_QA_06 authorize item== | ==UC_PM_QA_06 authorize item== | ||
| Line 110: | Line 110: | ||
*Schedule:'''R3''' | *Schedule:'''R3''' | ||
===Triggers=== | ===Triggers=== | ||
*The user wants to authorize an item. | |||
===Actors=== | ===Actors=== | ||
*Authority | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*One item is selected. | |||
*The last item version is in state “submitted”. | |||
===Flow of Events=== | ===Flow of Events=== | ||
| Line 125: | Line 125: | ||
*5. The system displays a success message (MSG_PM_QA_06). The use case ends successfully. | *5. The system displays a success message (MSG_PM_QA_06). The use case ends successfully. | ||
===Post-Conditions / Results=== | ===Post-Conditions / Results=== | ||
*None | |||
==UC_PM_QA_07 send item back for formal check== | ==UC_PM_QA_07 send item back for formal check== | ||
| Line 133: | Line 133: | ||
*Schedule:'''R3''' | *Schedule:'''R3''' | ||
===Triggers=== | ===Triggers=== | ||
*The user wants to send an item back for formal check. | |||
===Actors=== | ===Actors=== | ||
*Authority | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*One item is selected. | |||
*The last item version is in state “submitted”. | |||
===Flow of Events=== | ===Flow of Events=== | ||
| Line 148: | Line 148: | ||
*5. The system stores the information and displays a success message (MSG_PM_QA_07). The use case ends successfully. | *5. The system stores the information and displays a success message (MSG_PM_QA_07). The use case ends successfully. | ||
===Post-Conditions / Results=== | ===Post-Conditions / Results=== | ||
*None | |||
==UC_PM_QA_08 release item== | ==UC_PM_QA_08 release item== | ||
| Line 156: | Line 156: | ||
*Schedule:'''R1''' | *Schedule:'''R1''' | ||
===Triggers=== | ===Triggers=== | ||
*The item has to be released. | |||
''Comment Natasa: Last item version'' | ''Comment Natasa: Last item version'' | ||
===Actors=== | ===Actors=== | ||
*System | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*One item is selected. | |||
*The last item version is in state “submitted”. | |||
===Flow of Events=== | ===Flow of Events=== | ||
| Line 171: | Line 171: | ||
*3. The system saves the data and displays a success message (MSG_PM_QA_08). The use case ends successfully. | *3. The system saves the data and displays a success message (MSG_PM_QA_08). The use case ends successfully. | ||
===Post-Conditions / Results=== | ===Post-Conditions / Results=== | ||
*The item version is in state “released”. | |||
==UC_PM_QA_09 withdraw item== | ==UC_PM_QA_09 withdraw item== | ||
| Line 179: | Line 179: | ||
*Schedule:'''R1''' | *Schedule:'''R1''' | ||
===Triggers=== | ===Triggers=== | ||
*The user wants to withdraw an item. | |||
===Actors=== | ===Actors=== | ||
*Depositor | |||
*Local Administrator | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*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=== | ===Flow of Events=== | ||
| Line 198: | Line 198: | ||
*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. | *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=== | ===Post-Conditions / Results=== | ||
*The item is in state “withdrawn”. | |||
==UC_PM_QA_10 accept and authorize item== | ==UC_PM_QA_10 accept and authorize item== | ||
| Line 206: | Line 206: | ||
*Schedule:'''to be defined''' | *Schedule:'''to be defined''' | ||
===Triggers=== | ===Triggers=== | ||
*The user wants to accept and authorize an item. | |||
===Actors=== | ===Actors=== | ||
*Moderator | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*One item is selected. | |||
*The last item version is in state “submitted”. | |||
===Flow of Events=== | ===Flow of Events=== | ||
| Line 225: | Line 225: | ||
*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 | |||
==UC_PM_QA_11 modify item== | ==UC_PM_QA_11 modify item== | ||
| Line 234: | Line 234: | ||
===Triggers=== | ===Triggers=== | ||
*The user wants to modify an item. | |||
===Actors=== | ===Actors=== | ||
*Depositor | |||
*Further actors depending on the modification workflow of the item’s collection | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*One item is selected. | |||
*The last item version is in state “released”. | |||
===Flow of Events=== | ===Flow of Events=== | ||
| Line 251: | Line 251: | ||
*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. | *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=== | ===Post-Conditions / Results=== | ||
*The item is in state “pending” or “submitted”. | |||
*The item data is saved. | |||
==UC_PM_QA_13 revert to last released version== | ==UC_PM_QA_13 revert to last released version== | ||
| Line 260: | Line 260: | ||
*Schedule:'''to be defined''' | *Schedule:'''to be defined''' | ||
===Triggers=== | ===Triggers=== | ||
*The user wants to revert the item to the last released version. | |||
===Actors=== | ===Actors=== | ||
*Moderator | |||
*Metadata Editor | |||
===Pre-Conditions=== | ===Pre-Conditions=== | ||
*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=== | ===Flow of Events=== | ||
| Line 280: | Line 280: | ||
*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. | *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=== | ===Post-Conditions / Results=== | ||
*All item versions after the last released version are deleted. | |||
[[Category:PubMan]] | [[Category:PubMan]] | ||
[[Category:Functional_specification]] | [[Category:Functional_specification]] | ||
Revision as of 09:11, 29 November 2007
|
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: not implemented
- Schedule:R3
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.
Comment Natasa: Last item version 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”.
Comment Natasa: Why for validation point “submit” should not the validation point be “release”? (i.e. the validation point “submit” is already “passed” during the submission of an item.)
Comment uat: Agree. ..or rather include rules for validation point “accept”
Comment Inga: In the func team meetings, we agreed that the "pre-checker/helfershelfer" is enriching the existing metadata record, but not responsible for the quality assurance. Therefore, he should not be able to deliver a "poorer" record than submitted (-> validation point "submit"), but be free to post a record which does not confirm to the rules for "accept" to the Moderator. We believe it might be possible that the Helfershelfer is not able to investigate required metadata. If you want to change something, please introduce an explicit validation point "pre check"
- 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.
Comment Natasa: Not clear: what is this comment about and where is this comment kept?
Comments Inga: An exemplary comment would be "I was not able to find the issn". The comment should be continuously available via the item event log. We gave some more information in PubMan system spec, chapter "FE_PM_09 Logging": All executed actions in the system have to be logged with information about the action, the timestamp of execution, the user who executed the action, the object, if existent the version of the object on which the execution has been done and an action comment if provided by the user (see use cases)."
- 7. The system displays a success message (MSG_PM_QA_02). The use case ends successfully.
Post-Conditions / Results[edit]
- None
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: implemented
- Schedule:R2
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.
Comment Natasa: To clarify where is this comment kept? Item event log?
- 7. The system displays a success message (MSG_PM_QA_04). The use case ends successfully.
Post-Conditions / Results[edit]
- None
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.
Comment Natasa: Last item version
Status/Schedule[edit]
- Status: not implemented
- Schedule:R3
Triggers[edit]
- The user wants to send an item back for rework.
Comment Natasa: The last item version
Actors[edit]
- Metadata Editor
- Moderator
- Authority
Pre-Conditions[edit]
- One item is selected.
Comment Natasa: The last item version
- 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”.
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: not implemented
- Schedule:R3
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
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: not implemented
- Schedule:R3
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
UC_PM_QA_08 release item[edit]
The system releases the last version of the item.
Status/Schedule[edit]
- Status: implemented
- Schedule:R1
Triggers[edit]
- The item has to be released.
Comment Natasa: Last item version
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”.
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”.
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: not implemented
- Schedule:to be defined
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
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: implemented
- Schedule:R2
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.
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: not implemented
- 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.