The following text describes the domain and requirements of a university library management system. The library management system must support the following transactions: . . . . . . Checking-out/return of books to and from the library Accepting and processing book purchase requests from library users Engaging in online procurement transactions with book suppliers/publishers Adding/removing books from the library collection Supporting catalogue searches by author, title, keyword etc. Maintaining a list of books currently checked out by a given user Supporting self-checkout and online renewal by users Accepting and processing book, periodical requests as well as requests for online databases from academic departments and faculties Generating management reports (financial statements, activity statements and other performance measures) for university administration . . . There are three types of users: academic staff, research students and others (these include non-research students, other university staff and members of the broader community). Book purchase requests from academic staff and research students are accorded higher priority over requests from others. Actual purchase decisions need to take into consideration financial constraints. Requests from academic departments and faculties are always honoured, but they must fund these purchases/acquisitions. Users expect correct, accurate and consistent processing of all transactions. They also expect as many of their purchase requests to be honoured as possible. University administration expects the library to maximize user satisfaction while minimizing costs. Develop an i* model of the setting described above [including both Strategic Dependency (SD) and Strategic Rationale (SR) diagrams). Remember that the description might not provide all of the detail necessary to develop the model - you must complete the gaps by providing plausible information based on your understanding of the domain. Remember also that not all of the description can (or should) be included in the model you develop. The following text describes the domain and requirements of a university library management system. The library management system must support the following transactions: . . . . . . Checking-out/return of books to and from the library Accepting and processing book purchase requests from library users Engaging in online procurement transactions with book suppliers/publishers Adding/removing books from the library collection Supporting catalogue searches by author, title, keyword etc. Maintaining a list of books currently checked out by a given user Supporting self-checkout and online renewal by users Accepting and processing book, periodical requests as well as requests for online databases from academic departments and faculties Generating management reports (financial statements, activity statements and other performance measures) for university administration . . . There are three types of users: academic staff, research students and others (these include non-research students, other university staff and members of the broader community). Book purchase requests from academic staff and research students are accorded higher priority over requests from others. Actual purchase decisions need to take into consideration financial constraints. Requests from academic departments and faculties are always honoured, but they must fund these purchases/acquisitions. Users expect correct, accurate and consistent processing of all transactions. They also expect as many of their purchase requests to be honoured as possible. University administration expects the library to maximize user satisfaction while minimizing costs. Develop an i* model of the setting described above [including both Strategic Dependency (SD) and Strategic Rationale (SR) diagrams). Remember that the description might not provide all of the detail necessary to develop the model - you must complete the gaps by providing plausible information based on your understanding of the domain. Remember also that not all of the description can (or should) be included in the model you develop
