Use-Case View

The Architecturally significant Use Cases identified during the High Level Architecture definition are listed below. The diagram provides the model for architecturally significant use cases.

Figure 2 – Architecturally Significant Use-Case View

The following table lists the actors (user or system) interacting with the system.

The following lists the architecturally significant Use Cases.

A brief description of the architecturally significant use cases has been listed below. Each of the use case description includes key business rules and includes reasons for architectural significance.

Search Shared Collection Items

In this use-case the patron will search the OPAC for institution items as well as shared collection items placed by other ReCAP partners. Search for an item in OPAC will initiate search to OPAC’s index and ReCAP index. The two search results will be merged to include shared collection items in the search results.

Architectural Significance

• Core Functionality
• Complexities –Includes collecting bibliographic and item data from all three partners, normalizing and indexing the data and providing offline feed or API for OPAC systems.

Request Item

In this use-case a patron will request a ReCAP item by submitting the request through a web form. The form will submit the request to middleware API, which will invoke other use-cases to process the request.

Architectural Significance

• Core Functionality
• Complexities – ReCAP middleware will interact with GFA LAS, ILS and OPAC to process the request. It will create a temporary item record in one of the three applicable ILS depending upon the patron.

Validate Request

Request item use-case will invoke this use-case to validate the request for requested item, delivery location, delivery type, etc. Upon successful validation control will be returned to the main use-case with a confirmation message and upon unsuccessful validation an error message will be returned.

Architectural Significance

• Core Functionality
• Complexities – ReCAP middleware will validate against ReCAP circulation policies and item availability in the middleware database.

Place Hold on Item

In this use-case a patron will place hold against an item whose status is currently unavailable.

Architectural Significance

• Core Functionality
• Complexities – ReCAP middleware will maintain a single hold queue for all the partner institutions in a first-in, first-out basis. The hold queue will be automatically propagated to all applicable ILS systems.

Recall Item

In this use-case a patron/library staff will recall an item whose status is currently unavailable.

Architectural Significance

• Core Functionality
• Complexities – ReCAP middleware will interact with owning or borrowing institution ILS to send the Recall request and maintain the queue in middleware database.

Accession Item

In this use-case Library Staff will upload bib and item records for new ReCAP items. ReCAP middleware will interface with GFA LAS to check the accessioned item status and then apply accessioning algorithm.

Applying accessioning algorithm will result in one of the following three scenarios. A valid collection code will be assigned after which the item will be a shared collection item. It might also result in duplicates in which case, the items might be placed under institutional access instead of shared access. Detecting duplicates might also result in libraries withdrawing their items. So the proposed accessions are the items which are sent by Library staff for accessioning and actual accessions are the items which are assigned collection code after running the accessioning algorithm. Item information with assigned collection codes will be returned back to the owning libraries through SFTP drop. ReCAP staff also participates in the accessioning of an item

Architectural Significance

• Core Functionality
• Complexities – Accessioning algorithm will be run every time an item is accessioned in ReCAP. Accessioning algorithm includes a tie-breaker to cover most of the scenarios. Match and normalize disparate bib and item data across three partner ILS and GFA LAS. The item barcodes and applied circulation codes data will be returned to owning partner ILS.

DeAccession Item

In this use case Library Staff will initiate a request to deaccession an item through staff interfaces. Based on the collection code a manual approval workflow will be triggered to deaccession the item. ReCAP staff also participates in the deaccessioning of an item

Architectural Significance

• Core Functionality
• Complexities – ReCAP middleware will run accessioning algorithm to reassign circulation codes for other items after deaccessioning an item. A review/approval workflow will be implemented to manage preservation collections.

Process Borrow Direct Request

This use-case will be invoked by ReCAP staff to process a Borrow direct request. The staff will scan the barcode in the Borrow direct request or enter one if barcode not available. Upon matching the barcode the staff can invoke the request item use case by clicking the confirmation button.

Architectural Significance

• Core Functionality
• Complexities – ReCAP middleware will provide a thick client interface for barcode scanning to the ReCAP staff. The solution will maintain existing workflow for ReCAP staff and integrate the solution to middleware.

Re-file Item

In this use-case middleware will poll GFA LAS for re-filed items periodically, if an item is re-filed and has no hold or recall queue against it, its status will be changed to available. If a hold/recall queue exists the item will be processed for the first patron in the queue.

Architectural Significance

• Core Functionality
• Complexities – ReCAP middleware will actively poll GFA LAS to get the current status of the item. Once the item is checked-in (GFA), ReCAP middleware will process the item for next patron in queue and update corresponding ILS system.

Check Item Availability

In this use-case OPAC will request for a real-time availability status of an item from ReCAP middleware. Middleware API will return the status from the index which is maintained in sync with the transaction database.

Architectural Significance

• Core Functionality
• Complexities – Real-time Item status will be provided through search API which is maintained in sync with the ReCAP database. Update search engine index without performance degradation.

Get Shared Collection Records

In this use-case OPAC systems will retrieve the other partner’s shared collection records from SFTP server. The bib and item record will be normalized during inbound process and will be de-normalized during the outbound process to fit each partner’s needs. The outbound records will be limited to other institution’s shared collection items.

Architectural Significance

• Core Functionality
• Complexities –De-normalizing feeds for five OPAC systems.

Submit Collection Information

In this use-case partner ILS system will provide collection information, new accessioned and updates to bibliographic data through SFTP upload. Middleware will process data from all partners, normalize the data and ingest into middleware database. The normalized data will be updated to ReCAP index.

Architectural Significance

• Core Functionality
• Complexities – – Normalizing bib and item data from three ILS systems and de-normalizing feeds for five OPAC systems

Receive Collection Updates

In this use-case the ILS systems will retrieve collection updates from ReCAP middleware through SFTP drops. ReCAP middleware will de-normalize the data sets and provide updated collection information of item records pertinent to requesting institution only.

Architectural Significance

• Core Functionality
• Complexities – Identifying the collection update and provide offline export of owning library items only.