Talk:PubMan Func Spec Quality Assurance

Discussion on PubMan_Funtional_Specification - Quality Assurance

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.

Status/Schedule

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

Triggers

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

Actors

• Metadata Editor

Pre-Conditions

• Last item version is selected and in state “submitted”.

Flow of Events

• 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

• 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". --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)

UC_PM_QA_03 accept item

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

Status/Schedule

• Status: in design
• Schedule:R3

Triggers

• The user wants to accept an item.

Actors

• Moderator

Pre-Conditions

• One item is selected.

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

Flow of Events

• 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. The system displays a success message (MSG_PM_QA_04). The use case ends successfully.

Post-Conditions / Results

• None

Future Development

• 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)

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.

Status/Schedule

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

Triggers

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

Actors

• Metadata Editor

• Moderator

• Authority

Pre-Conditions

• Last item version is selected.

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

Flow of Events

• 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

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

Future Development

Find a solution for the follwing problem:

• Comment Natasa: In the standard modification workflow Authority is not depicted for "UC_PM_QA_04 send item back for rework" but only for the standard publication workflow. Is this on purpose or is omitted?--Natasa 15:12, 17 January 2008 (CET)

UC_PM_QA_06 authorize item

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

Status/Schedule

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

Triggers

• The user wants to authorize an item.

Actors

• Authority

Pre-Conditions

• One item is selected.

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

Flow of Events

• 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

• None

UC_PM_QA_07 send item back for formal check

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

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

Triggers

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

Actors

• Authority

Pre-Conditions

• One item is selected.

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

Flow of Events

• 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

• 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?)--Natasa 14:47, 17 January 2008 (CET)

UC_PM_QA_08 release item

The system releases the last version of the item.

Status/Schedule

• Status: in design
• Schedule:R3

Triggers

• The last item version has to be released.

Actors

• System

Pre-Conditions

• One item is selected.

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

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.
• 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

• The item version is in state “released”.

UC_PM_QA_09 withdraw item

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: implemented
• Schedule:R1

Triggers

• The user wants to withdraw an item.

Actors

• Depositor
• The user is the owner of the item or the Local Administrator.

Flow of Events

• 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

• The item is in state “withdrawn”.

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?--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)

see AS-314 for functional details--Ulla 13:39, 20 March 2008 (CET)

UC_PM_QA_10 accept and authorize item

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

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

Triggers

• The user wants to accept and authorize an item.

Actors

• Moderator

Pre-Conditions

• One item is selected.

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

Flow of Events

• 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

• 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?--Natasa 14:50, 17 January 2008 (CET)

UC_PM_QA_11 modify item

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: in design
• Schedule:R3

Triggers

• The user wants to modify an item.

Actors

• Depositor

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

Pre-Conditions

• One item is selected.

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

Flow of Events

• 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”. Continue with 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

• 2a. The user has the role “Depositor”. The system creates a new item version with the status “pending”. Continue with 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

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

UC_PM_QA_13 revert to last released version

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

Status/Schedule

• Status: in specification
• Schedule:to be defined

Triggers

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

Actors

• Moderator

• Metadata Editor

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

• 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

• 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").--Natasa 13:30, 25 February 2008 (CET)

Workflow

please see PubMan workflows

HTML Prototype

Prototype Quality Assurance

Publication Management

Use Case

Quality Assurance

Graphical User Interface

Central European Time

Workflow

International Standard Serial Number

Persistent Identifer or Identification

Electronic Documentation

Fachinformationszentrum Karlsruhe

Hypertext Markup Language