Difference between revisions of "PubMan Func Spec Quality Assurance"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(51 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{PubMan_Funtional_Specification}}
{{PubMan_Funtional_Specification}}
==Scenarios==
Some scenarios to better understand the typical goals and motivations of users, to design a userfriendly "workspace". Detailled use cases can be found below.
===Release publications for feeding it into local webpage===
*WHO: librarian (see User groups)
*WHY: The librarian is in charge of checking any reference and attached fulltext, before it is released, i.e. publicly available. She wants to crosscheck and release the items of a certain department, so the data can be integrated into the local website. She is the only one who can do that and the scientific director is waiting for the updated publication list on the homepage.
*GOALS:
**Get an overview of all references of the departement which have not been released so far
**Sort or filter the list by priorities, in that case by organisational unit.
**check each item of the list, modify it if necessary and release it
===Check if all publications of specific department have high-level metadata===
*WHO: librarian
*WHY: The scientists are entering their data on their own via the easy submission. The librarian wants to cross-check bi-weekly, if the references entered should be completed with additional metadata for better search&retrieval.
*GOALS:
**Get an overview of all references released sofar, but not modified.
**Sort of filter the list by priorities, in that case by organsiationla unit.
**Check each item of the list, modify it  if necessary and release it.
===Check a specific item for wrong metadata===
*WHO: librarian
*WHY: The librarian has been informed by a scientist, that the paper he has submitted 3weeks ago is still not available on his website. The librarian wants to cross-chekc, if the metadata provided are correct. If not, the query for the publication might fail.
*GOALS:
**Search for a specific reference, in that case by author plus organisational unit plus title of paper.
**Check the result, identify the reference needed.
**Check the item, modify it if necessary and release it.
===Check which publications of the department have no OA fulltexts attached===
*WHO: librarian
*WHY: The scientific director has announced that all fulltexts of his department should be made available by OA, if no copyright restrictions. The librarian is the main contact point for the Open Access policy, therefore she prepares a workshop for supporting and promoting the idea of OA. For better preparation, she wants to get a list of all references which do not have an OA fulltext attached.
*GOALS:
**Search for references of the department
**Sort/Filter them by the criteria "no OA fulltext attached"
**Print out the list of references
==UC_PM_QA_01 confirm pre-check item==
==UC_PM_QA_01 confirm pre-check item==
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.
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.
Line 11: Line 45:
*Metadata Editor
*Metadata Editor
===Pre-Conditions===
===Pre-Conditions===
*One item is selected.
*Last item version is selected and in state “submitted”.
*The last item version is in state “submitted”.


===Flow of Events===
===Flow of Events===
Line 19: Line 52:
*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.
**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.
**b. The validation report status is invalid. The selected item is unaffected. The system displays an error message ([[PubMan_System_Messages|MSG_PM_QA_01]]). The use case ends without success.
*4. The system prompts for a comment.
*4. The system prompts for a comment.
*5. (Optionally) The user enters a comment.
*5. (Optionally) The user enters a comment.
*6. The user confirms the input.
*6. The user confirms the input.
*7. The system displays a success message (MSG_PM_QA_02). The use case ends successfully.
*7. The system displays a success message ([[PubMan_System_Messages|MSG_PM_QA_02]]). The use case ends successfully.


===Post-Conditions / Results===
===Post-Conditions / Results===
*None
*None
===Future Development===
Find solutions for the following problems:
''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"''
''Comment Natasa: But then it seems like it is not clear in which status the item finishes after the pre-check (post-condition is None). My comment for validation point "release" was due to the impression that after pre-check the item finishes in released state. On the other hand to me is unclear what this use case actually does - as from the description it seems only that it manually triggers the validation of the item and allows for editing the item event log i.e. this would mean a new version of an item is created with new log to my understanding. Otherwise in the description for this use case we need to state smth like "this use case is included by use case ..." ''
''Comment Inga: The "positioning" of this use case is defined via the workflow diagrams (see Systemspecification_Pubman.doc). This UC is currently not included from any other UC, but available after the previous event has been executed. The workflow diagram also includes the information in which nodes the item is editable. We made no assumption where the item event log is stored. Only editing the item should create a new version and no actions in the workflow. Regarding "post-condition", step 7 first formulated something like "The system marks the item as pre-checked and displays a success message...", but we deleted it because it should be clear from the workflow diagrams. Could be that the same use case is later used by another workflow which defines different exit points, i.e. "release item".'' --[[User:Inga|Inga]] 17:28, 30 December 2007 (CET)
''Comment Natasa: The standard modification workflow uses the validation point "accept" in the workflow diagram. That would be fine for pre-check item, as the helfer can enrich, can save the item, but can still generate the validation report and put short info in the event log for the moderator. In this case, validation point accept is not "restrictive" is rather "informative". Therefore would propose not to end the use case without success in case when the validation report is invalid, but to allow her to save the item, keep the event log and either revert to last released version (as in WF diagram depicted) or forward the task to the Moderator who will know what to do next. (Or it is my wrong understanding of what means ends with/without success :) ) --[[User:Natasab|Natasa]] 14:40, 17 January 2008 (CET) ''
AND:
''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 time stamp 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)." ''
<span style="color:olive">It would be good to have a more common feedback option which can be also used to comment on the validation. Do we have librarians/scientists who are in need to comment even on a validation message? Rupert 16:31, 6 December 2007 (CET)</span>


===Discussion===
===Discussion===
Line 34: Line 92:
The user accepts the last item version because the formal quality of the item is good.
The user accepts the last item version because the formal quality of the item is good.
===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''implemented'''
*Schedule:'''R3'''
*Schedule:'''R3'''


Line 51: Line 109:
*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.
**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.
**b. The validation report status is invalid. The selected item is unaffected. The system displays an error message ([[PubMan_System_Messages|MSG_PM_QA_03]]). The use case ends without success.
*7. Continue with [[PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_08_release_item|UC_PM_QA_08 release item]]. The use case ends successfully.
 
===Post-Conditions / Results===
*None
 
===Future Development ===
 
*4. The system prompts for a comment.
*4. The system prompts for a comment.
*5. (Optionally) The user enters a comment for the check.
*5. (Optionally) The user enters a comment for the check.
*6. The user confirms the input.
*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===
''Has been postponed, because the framework doesn't support the comment yet. --[[User:Nicole|Nicole]] 15:48, 17 March 2008 (CET)''
*None


===Discussion===
===Discussion===
Line 65: Line 128:
==UC_PM_QA_04 send item back for rework==
==UC_PM_QA_04 send item back for rework==
The user is not satisfied with the item version data and therefore sends the item version back for rework to the Depositor.
The user is not satisfied with the item version data and therefore sends the item version back for rework to the Depositor.
===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''implemented'''
*Schedule:'''to be defined''' (depends on workflow engine)
*Schedule:'''R3.5'''


===Triggers===
===Triggers===
*The user wants to send an item back for rework.
*The user wants to send the last item version back for rework.


===Actors===
===Actors===
Line 80: Line 144:


===Pre-Conditions===
===Pre-Conditions===
*One item is selected.
*Last item version is selected.
 
*The last item version is in state “submitted”.
*The last item version is in state “submitted”.


Line 88: Line 153:
*3. (Optionally) The user specifies a comment.
*3. (Optionally) The user specifies a comment.
*4. The user confirms the input.
*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.
*5. The system changes the status of the item version to “in rework” and displays a success message ([[PubMan_System_Messages|MSG_PM_QA_05]]). The use case ends successfully.
 
===Post-Conditions / Results===
===Post-Conditions / Results===
*The item version is in state “in rework”.
*The item version is in state “in rework”.
===Future Development===


===Discussion===
===Discussion===
Line 115: Line 183:
*3. (Optionally) The user enters a comment for the check.
*3. (Optionally) The user enters a comment for the check.
*4. The user confirms the input.
*4. The user confirms the input.
*5. The system displays a success message (MSG_PM_QA_06). The use case ends successfully.
*5. The system displays a success message ([[PubMan_System_Messages|MSG_PM_QA_06]]). The use case ends successfully.
 
===Post-Conditions / Results===
===Post-Conditions / Results===
*None
*None
Line 142: Line 211:
*3. (Optionally) The user specifies a comment.
*3. (Optionally) The user specifies a comment.
*4. The user confirms the input.
*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.
*5. The system stores the information and displays a success message ([[PubMan_System_Messages|MSG_PM_QA_07]]). The use case ends successfully.
===Post-Conditions / Results===
===Post-Conditions / Results===
*None
*None
===Further development===
* ''Comment Natasa: do we need to think if the authority can only send the item back for formal check or immediately can reject this item? (i.e. what happens if authority is not satisfied with the content of the item and would not like to do anything further about this item?)''--[[User:Natasab|Natasa]] 14:47, 17 January 2008 (CET)
===Discussion===
===Discussion===
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_07_send_item_back_for_formal_check]]
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_07_send_item_back_for_formal_check]]
Line 151: Line 223:
The system releases the last version of the item.
The system releases the last version of the item.
===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''implemented R4''', '''in rework R5'''
*Schedule:'''R3'''
*Schedule:'''R5'''


===Triggers===
===Triggers===
Line 159: Line 231:
===Actors===
===Actors===
*System
*System
:For release R5 the actor is Depositor or Moderator --[[User:Natasab|Natasa]] 14:14, 14 May 2009 (UTC)
===Pre-Conditions===
===Pre-Conditions===
*One item is selected.
*One item is selected.
Line 166: Line 240:
===Flow of Events===
===Flow of Events===
*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.
*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”.
*2.    Before the item is released a information message shows up: "You are going to release an item with rights information.    Please be aware that you have checked these information!"
*3. The system saves the data and displays a success message (MSG_PM_QA_08). The use case ends successfully.
**These information message shows up only if the user provides rights information (CC License, rights statement, date copyrighted) for the submitted item and its component(s).
*3. The system sets the state of the item version to “released”.
*4. Extension point: '''revoke audience privileges for files'''
** 4.1 If the released item version has files which have visibility level set from "audience" to "private" or "public" the system revokes all audience rights for files of an item , include [[PubMan_Func_Spec_User_Management#UC_PM_UM_12_Revoke_audience_privileges_for_files|UC_PM_UM_12_Revoke_audience_privileges_for_files]].
*5. The system saves the data and displays a success message ([[PubMan_System_Messages|MSG_PM_QA_08]]). If item has files with  "audience" level privileges, the system message is enriched with text "Please specify the privileges for files with visibility "audience" " (and with respective text in german). If The use case ends successfully.
 
===Post-Conditions / Results===
===Post-Conditions / Results===
*The item version is in state “released”.
*The item version is in state “released”.
Line 176: Line 255:
The owner of the item or the Local Administrator withdraws the item because the item should no longer be accessible via the IR.
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===
===Status/Schedule===
*Status: '''implemented'''
*Status: '''implemented'''  
*Schedule:'''R1'''
*Schedule:'''R1 (to be reworked in R3.5)'''
 
===Triggers===
===Triggers===
*The user wants to withdraw an item.
*The user wants to withdraw an item.
===Actors===
===Actors===
*Depositor
*Depositor
*Local Administrator
===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.
*The user is the owner of the item or the Local Administrator.


Line 196: Line 268:
*2. The system prompts for a reason for the withdrawal.
*2. The system prompts for a reason for the withdrawal.
*3. The user enters a reason and confirms 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.
*4. The system changes the state of the item to “withdrawn” and stores the withdrawal comment. The system displays a success message ([[PubMan_System_Messages|MSG_PM_QA_09]]). The use case ends successfully.
===Post-Conditions / Results===
===Post-Conditions / Results===
*The item is in state “withdrawn”.
*The item is in state “withdrawn”.
*For clarification on version statuses and comments see also discussion and example table at [[ESciDoc_Withdraw_Comment | Withdrawing operation]] and  [[Talk:ESciDoc_Withdraw_Comment | Discussion on withdrawing operation]]
===Future development===
Find a solution for the following problem:
''[Natasa]Must the last item version be in state released or there should be at least one released version of an item? The question is raised because users might have already started to edit the new version (there was at least one previously released version) and decides to withdraw an item - withdrawal can be done at any time to my understanding if there was a release before. Or we simply purge all non-released versions to the last released version and then withdraw the item?--[[User:Natasab|Natasa]] 14:16, 17 January 2008 (CET)''
Current implementation: once an item has been released, it can't be just saved anymore. One can only directly release it or cancel the modification process. --[[User:Nicole|Nicole]] 15:17, 18 March 2008 (CET)
===Discussion===
===Discussion===
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_09_withdraw_item]]
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_09_withdraw_item]]
Line 222: Line 303:
*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.
**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.
**b. The validation report status is invalid. The selected item is unaffected. The system displays an error message ([[PubMan_System_Messages|MSG_PM_QA_03]]). The use case ends without success.
*4. The system prompts for a comment.
*4. The system prompts for a comment.
*5. (Optionally) The user enters a comment.
*5. (Optionally) The user enters a comment.
*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 ([[PubMan_System_Messages|MSG_PM_QA_10]]). The use case ends successfully.


===Post-Conditions / Results===
===Post-Conditions / Results===
*None
*None
===Further development===
*''Comment Natasa: On eDoc we had this case, but Moderators were having a requirements smth. like "On Behalf Of" ... Is this ommited on purpose from this use case spec or is no longer relevant?''--[[User:Natasab|Natasa]] 14:50, 17 January 2008 (CET)
===Discussion===
===Discussion===
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_10_accept_and_authorize_item]]
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_10_accept_and_authorize_item]]
Line 236: Line 321:
The user modifies an released item by providing additional data, correcting or deleting existing values. With this action he starts the modification workflow.
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===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''implemented'''
*Schedule:'''R3'''
*Schedule:'''R3'''


Line 253: Line 338:
===Flow of Events===
===Flow of Events===
*1. The user chooses to modify an item.
*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.
*2. The user has a role other than “Depositor”. Include use case [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|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.
*3. Continue with [[PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_03_accept_item|UC_PM_QA_03_accept_item]]. The use case ends successfully.
 
===Alternatives===
===Alternatives===
*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 [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|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”.
*none
*The item data is saved.
 
===Discussion===
===Discussion===
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_11_modify_item]]
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_11_modify_item]]
Line 287: Line 375:
*3. (Optionally) The user enters a comment for the deletion of the item 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.
*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.
*5. The system deletes the item versions back to the last released version and displays a success message ([[PubMan_System_Messages|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.
*All item versions after the last released version are deleted.
===Constraints===
* it is at present not possible to update the item event log without affecting the version. The item event log is automatically maintained by FIZ whenever a new version is created or a status change is done (note: only status changes supported directly from the item handler and not status changes such as "accept", "authorize").--[[User:Natasab|Natasa]] 13:30, 25 February 2008 (CET)
===Discussion===
===Discussion===
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_13_revert_to_last_released_version]]
[[Talk:PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_13_revert_to_last_released_version]]
Line 297: Line 391:


==HTML Prototype==
==HTML Prototype==
[https://zim01.gwdg.de/repos/smc/trunk/04_Design/03_GUI_Design/03_Prototyping/HTML-Prototyp/10_Quality_Assurance/index.html Prototype Quality Assurance]


[[Category:PubMan]]
* The publicly available '''HTML prototype for quality assurance''' and for other functionalities can be accessed from here: [[ESciDoc_Prototyping#PubMan_Prototype|eSciDoc Prototyping]].
[[Category:Functional_specification]]
 
'''Please note that this is work in progress and will be changed.'''
 
[[Category:PubMan_Functional_Specification|Quality_Assurance]]

Latest revision as of 09:50, 4 August 2009

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

Scenarios[edit]

Some scenarios to better understand the typical goals and motivations of users, to design a userfriendly "workspace". Detailled use cases can be found below.

Release publications for feeding it into local webpage[edit]

  • WHO: librarian (see User groups)
  • WHY: The librarian is in charge of checking any reference and attached fulltext, before it is released, i.e. publicly available. She wants to crosscheck and release the items of a certain department, so the data can be integrated into the local website. She is the only one who can do that and the scientific director is waiting for the updated publication list on the homepage.
  • GOALS:
    • Get an overview of all references of the departement which have not been released so far
    • Sort or filter the list by priorities, in that case by organisational unit.
    • check each item of the list, modify it if necessary and release it

Check if all publications of specific department have high-level metadata[edit]

  • WHO: librarian
  • WHY: The scientists are entering their data on their own via the easy submission. The librarian wants to cross-check bi-weekly, if the references entered should be completed with additional metadata for better search&retrieval.
  • GOALS:
    • Get an overview of all references released sofar, but not modified.
    • Sort of filter the list by priorities, in that case by organsiationla unit.
    • Check each item of the list, modify it if necessary and release it.

Check a specific item for wrong metadata[edit]

  • WHO: librarian
  • WHY: The librarian has been informed by a scientist, that the paper he has submitted 3weeks ago is still not available on his website. The librarian wants to cross-chekc, if the metadata provided are correct. If not, the query for the publication might fail.
  • GOALS:
    • Search for a specific reference, in that case by author plus organisational unit plus title of paper.
    • Check the result, identify the reference needed.
    • Check the item, modify it if necessary and release it.

Check which publications of the department have no OA fulltexts attached[edit]

  • WHO: librarian
  • WHY: The scientific director has announced that all fulltexts of his department should be made available by OA, if no copyright restrictions. The librarian is the main contact point for the Open Access policy, therefore she prepares a workshop for supporting and promoting the idea of OA. For better preparation, she wants to get a list of all references which do not have an OA fulltext attached.
  • GOALS:
    • Search for references of the department
    • Sort/Filter them by the criteria "no OA fulltext attached"
    • Print out the list of references

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]

  • Last item version is selected and 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

Future Development[edit]

Find solutions for the following problems:

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"

Comment Natasa: But then it seems like it is not clear in which status the item finishes after the pre-check (post-condition is None). My comment for validation point "release" was due to the impression that after pre-check the item finishes in released state. On the other hand to me is unclear what this use case actually does - as from the description it seems only that it manually triggers the validation of the item and allows for editing the item event log i.e. this would mean a new version of an item is created with new log to my understanding. Otherwise in the description for this use case we need to state smth like "this use case is included by use case ..."

Comment Inga: The "positioning" of this use case is defined via the workflow diagrams (see Systemspecification_Pubman.doc). This UC is currently not included from any other UC, but available after the previous event has been executed. The workflow diagram also includes the information in which nodes the item is editable. We made no assumption where the item event log is stored. Only editing the item should create a new version and no actions in the workflow. Regarding "post-condition", step 7 first formulated something like "The system marks the item as pre-checked and displays a success message...", but we deleted it because it should be clear from the workflow diagrams. Could be that the same use case is later used by another workflow which defines different exit points, i.e. "release item". --Inga 17:28, 30 December 2007 (CET)

Comment Natasa: The standard modification workflow uses the validation point "accept" in the workflow diagram. That would be fine for pre-check item, as the helfer can enrich, can save the item, but can still generate the validation report and put short info in the event log for the moderator. In this case, validation point accept is not "restrictive" is rather "informative". Therefore would propose not to end the use case without success in case when the validation report is invalid, but to allow her to save the item, keep the event log and either revert to last released version (as in WF diagram depicted) or forward the task to the Moderator who will know what to do next. (Or it is my wrong understanding of what means ends with/without success :) ) --Natasa 14:40, 17 January 2008 (CET)

AND:

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 time stamp 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)."

It would be good to have a more common feedback option which can be also used to comment on the validation. Do we have librarians/scientists who are in need to comment even on a validation message? Rupert 16:31, 6 December 2007 (CET)


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: implemented
  • 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.
  • 7. Continue with UC_PM_QA_08 release item. The use case ends successfully.

Post-Conditions / Results[edit]

  • None

Future Development[edit]

  • 4. The system prompts for a comment.
  • 5. (Optionally) The user enters a comment for the check.
  • 6. The user confirms the input

Has been postponed, because the framework doesn't support the comment yet. --Nicole 15:48, 17 March 2008 (CET)

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: implemented
  • Schedule:R3.5

Triggers[edit]

  • The user wants to send the last item version back for rework.

Actors[edit]

  • Metadata Editor
  • Moderator
  • Authority

Pre-Conditions[edit]

  • Last item version 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”.

Future Development[edit]

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

Further development[edit]

  • Comment Natasa: do we need to think if the authority can only send the item back for formal check or immediately can reject this item? (i.e. what happens if authority is not satisfied with the content of the item and would not like to do anything further about this item?)--Natasa 14:47, 17 January 2008 (CET)

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: implemented R4, in rework R5
  • Schedule:R5

Triggers[edit]

  • The last item version has to be released.

Actors[edit]

  • System
For release R5 the actor is Depositor or Moderator --Natasa 14:14, 14 May 2009 (UTC)

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. Before the item is released a information message shows up: "You are going to release an item with rights information. Please be aware that you have checked these information!"
    • These information message shows up only if the user provides rights information (CC License, rights statement, date copyrighted) for the submitted item and its component(s).
  • 3. The system sets the state of the item version to “released”.
  • 4. Extension point: revoke audience privileges for files
  • 5. The system saves the data and displays a success message (MSG_PM_QA_08). If item has files with "audience" level privileges, the system message is enriched with text "Please specify the privileges for files with visibility "audience" " (and with respective text in german). If 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 (to be reworked in R3.5)

Triggers[edit]

  • The user wants to withdraw an item.

Actors[edit]

  • Depositor
  • 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]

Future development[edit]

Find a solution for the following problem:

[Natasa]Must the last item version be in state released or there should be at least one released version of an item? The question is raised because users might have already started to edit the new version (there was at least one previously released version) and decides to withdraw an item - withdrawal can be done at any time to my understanding if there was a release before. Or we simply purge all non-released versions to the last released version and then withdraw the item?--Natasa 14:16, 17 January 2008 (CET)

Current implementation: once an item has been released, it can't be just saved anymore. One can only directly release it or cancel the modification process. --Nicole 15:17, 18 March 2008 (CET)

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

Further development[edit]

  • Comment Natasa: On eDoc we had this case, but Moderators were having a requirements smth. like "On Behalf Of" ... Is this ommited on purpose from this use case spec or is no longer relevant?--Natasa 14:50, 17 January 2008 (CET)

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: implemented
  • 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”. 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.
  • 3. Continue with UC_PM_QA_03_accept_item. 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]

  • none

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.

Constraints[edit]

  • it is at present not possible to update the item event log without affecting the version. The item event log is automatically maintained by FIZ whenever a new version is created or a status change is done (note: only status changes supported directly from the item handler and not status changes such as "accept", "authorize").--Natasa 13:30, 25 February 2008 (CET)

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]

  • The publicly available HTML prototype for quality assurance and for other functionalities can be accessed from here: eSciDoc Prototyping.

Please note that this is work in progress and will be changed.

Publication Management

Open Access

Use Case

Quality Assurance

Graphical User Interface

Central European Time

Workflow

International Standard Serial Number

Coordinated Universal Time

Persistent Identifer or Identification

Creative Common

Electronic Documentation

Fachinformationszentrum Karlsruhe

Hypertext Markup Language

Retrieved from "https://colab.mpdl.mpg.de/mw010/index.php?title=PubMan_Func_Spec_Quality_Assurance&oldid=40799"