Application Modelling: Macquarie University Library System - Report Example

Macquarie University Library System (MULS); Modelling and Development Author: xxxxxxxx Macquarie University March 2016 Table of Contents 1.Introduction 1 1.1Why develop the system? 1 1.2Conventions Observed 1 1.3Target Users 1 1.4Reference 1 2.System Outline 2 2.1System Context 2 2.2Functions of MULS 3 2.2.1Administrators 3 2.2.2Students 4 2.2.3Library staff 4 2.2.4 Other Staff 4 2.3Classification of Users 5 2.4System Environment 5 2.5Challenges in Design and Implementation 5 2.6Documentation 5 2.7Development Assumptions 5 3.Interface Requirements 6 3.1User Interfaces 6 3.2Hardware Requirements 6 3.3Software Requirements 6 3.4Communications Interfaces 6 4.Other Requirements 7 4.1Gathering Requirements 7 4.1.1Interviews. 7 4.1.2The questionnaires; 7 4.1.3Task Analysis; 7 4.2System Performance Requirements 8 4.3Access Requirements 8 4.4System Attributes 8 5.Future Requirements 8 6.Features of MULS 9 6.1Student User Module 9 6.1.1Data and Error Handling 9 6.1.2Stimulus Sequences 9 6.1.3Functional Requirements 9 6.2Admin/Library Staff User Module 9 6.2.1Data and Error Handling 9 6.2.2Stimulus Sequences 9 6.2.3Functional Requirements 10 7.The Envisaged System 11 8.Does the document pass requirements review? 11 Glossary 12 1. Introduction 1.1 Why develop the system? A user-friendly environment for maintaining a catalogue of books and member information is the primary reason for developing Macquarie University Library System. MULS is a system to be used by the university’s library staff and department to improve the effectiveness of and efficiency of tasks performed by the librarian, staff and students. It provides book's catalogue and information to members for decision making. 1.2 Conventions Observed The document only describes the requirements specifications for the LMS. It does not provide any references to other sub-systems. It also identifies the external interfaces and the dependencies. The overall scope of the feasibility study is to enable an accurate making of the decision on the LMS requirements and prioritization of tasks. 1.3 Target Users The document targets the library stakeholders including students as well as the programmers and developers. Furthermore, it would be of help to the University management in the running of the library department. 1.4 Reference Mall, R. (2014). Fundamentals of software engineering. PHI Learning Pvt. Ltd. books.google.co.in/books?isbn=8120348982 2. System Outline 2.1 System Context LMS is a replacement for the ordinary library management systems which depend on paperwork for recording book and users’ information. LMS will provide an advanced book search mechanism and will make it easy to borrow, insert and index a book in the Library. Below is the context diagram for the system: Figure 2.1: Context Diagram for MULS 2.2 Functions of MULS 2.2.1 Administrators The administrators of MULS can perform the following functions concerning the daily operation of the new system: ability to edit book status; increase the period of borrowing a book for a particular type or group of users; ability to obtain member status report of any library member; add and edit book categories and arrange books by categories; add and select authors and publishers information; Administrators are tasked with sending lateness warnings to deadline defaulters They will also be able to record books returned by users. Figure 2.2: Use Case Diagram 2.2.2 Students The students should be provided with the updated information about the books catalogue. The students should be able to reserve a book which has been borrowed in advance. The students should be able to extend the borrowing period of the book so long as it hasn’t been reserved. Members have the ability to peruse available books by subject, title, authors or any information related to the book. Upon their request also, new books can be added to the library collection. Normal students should be able to borrow 5 books. Higher degree users should be able to request for books to be brought in from public libraries as well as borrow two extra books than other students. 2.2.3 Library staff The following functional options are available to library staff; Library staff should be able to modify book status; Appraisal of user membership applications; Generation of book status report and delivery of deadline warnings. Add and edit book categories and arrange books by categories. members are given a provision to check users account’s information and change it; Library staff can approve addition of requested books for purchasing; Staff users should be able to request for books to be brought in from public libraries. 2.2.4 Other Staff The staff should be provided with the updated information about the books catalogue; including ability to reserve a book which has been borrowed in advance. Ability to access personal account and edit information. Other staff can also search for books based on subject, title, authors or any information related to the book. Staff users should be able to request for books to be brought in from public libraries as well as borrow at any one time a total of seven books. 2.3 Classification of Users The users of the LMS are students, staff, and the administrators who maintain the website. Students and staff are assumed to have basic computer internet browsing knowledge. System administrators should have more knowledge of internal modules of the system and can rectify minor problems that may come up due to disk crashes, power failures, and other catastrophes. The simple online help and guide ought to be comprehensive and useful to the users. 2.4 System Environment The LMS is a website and shall operate in all famous browsers, such as Microsoft Edge, Mozilla Firefox with Flash Player and JavaScript. 2.5 Challenges in Design and Implementation The design will only have a working timeframe of a year within which all the various components have to be created tested and implemented. This time constraint will not enable all the features to be implemented before the launch. The rush may also lead to missed data during the initial stages. 2.6 Documentation User documentation will be made available on the help section of the library management system. 2.7 Development Assumptions The following assumptions are made: i. The maximum number of books each user can borrow is determined by the id type stored on the system. ii. The number of books borrowed rule is enforced by the library management system which bars you from borrowing any other books until the count of the number of books associated with your account goes below your maximum. iii. The user privileges are determined by the type of account that is used to log in. iv. This system will depend on the HROnline system for staff fine payments. 3. Interface Requirements 3.1 User Interfaces The user interface systems are expected to be clear and concise in the layout. No clutter will be allowed in the interface. The color pallet of the interface will include the university colors to create a professional looking product. 3.2 Hardware Requirements The system will include a network of servers controlled by the administrators and library staff. Students and other users will get credentials from the library staff that will enable them to access the library management system from their devices. Supported client devices will include tablets, laptops and smartphones. 3.3 Software Requirements The library will provide a standalone app for smartphone devices running on android and IOS. Laptops and other computers will be able to access the LMS through any updated browsers. 3.4 Communications Interfaces Communication functions required by this product, include e-mail, web browser, network server communications protocols, electronic forms, and so on. The system will implement the use of both FTP and HTTP for communication between devices. HTTPS will be used for the login screen to provide an added layer of security. 4. Other Requirements 4.1 Gathering Requirements 4.1.1 Interviews. It occurs when the requirements engineer discusses critical issues with stakeholders or with future system users, in this case, the students and staff. The interview has three basic types; structured, semi-structured and unstructured. The most valuable for the requirements definition is the unstructured case. It has to be held by some experienced engineer. The structured interview commonly leads to missed essential requirements if the set of questions is not well prepared and structured. A well-working compromise; the semi-structured interview, where an essential set of the question is prepared and used. Besides, brainstorming is a very useful addition to the semi-structured interview. If there are more than one stakeholders, the whole group is questioned at the same time. The answers and discussions of the entire group are noted. Laddering, another technique, which is used as part of the brainstorming allows analysing the debate and brings hierarchical structures of stakeholder’s answers. 4.1.2 The questionnaires; It is very useful in preliminary requirements gathering technique. The questionnaires lack in discovering new facts or dimensions of the proposed system. It is advantageous since it doesn’t require a very long time to collect information using this method. 4.1.3 Task Analysis; Through a top-down approach, the higher ranking tasks are designed first followed by the description of all other sub-task and can be documented in the form of system stories. The observation; a method, which comes to system engineering from the ethnography and other sociological research. The observation allows observing users in their environment. MULS being a human-centric system, this method can be applied 4.2 System Performance Requirements MULS ought to be able to handle a vast catalogue of books without system failures or bugs. 4.3 Access Requirements The systems access and privileges will be determined by the login credentials provided after registration into the library management system. The credentials will be further protected during the login process by use of the HTTPS protocols. 4.4 System Attributes The system will give priority to the adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Ease of use over ease of learning is preferable as special help tips can be added to direct new users. 5. Future Requirements The system should be able to automatically notify users who have approached the due date an hour before the close of the due day. The system should be able to notify staff and student members who requested a book brought in the moment its deadline arrives. 6. Features of MULS 6.1 Student User Module 6.1.1 Data and Error Handling This system will allow for sensitive data to be handled using HTTPS. It will also allow for data to be handled in such a ways as even in major catastrophic events the sensitive data will not get lost. 6.1.2 Stimulus Sequences Data is manually entered by the users i.e. admins, staff and students. The data can then be viewed based on access level restrictions 6.1.3 Functional Requirements Can record books returned by user. Book receive: In this module we can a book into our account. Book record: In this module we can keep the records of various books being issued and returned. REQ-1: Book Receive REQ-2: Book Record 6.2 Admin/Library Staff User Module 6.2.1 Data and Error Handling This system will allow for sensitive data to be handled using HTTPS. It will also allow for data to be handled in such a ways as even in major catastrophic events the sensitive data will not get lost. 6.2.2 Stimulus Sequences Data is manually entered by the users i.e. admins, staff and students using their respective devices. 6.2.3 Functional Requirements Add and edit book catalogue and arrange books by categories. Can record books returned by users. Book entry: In this module we can enter a new book and store it. Book issue: In this module we can issue a book to the student. Book record: In this module we can keep the records of various books being issued and returned. Register student/Staff: In this module we can keep the record of how many students registered REQ-1: Book received N/A REQ-2: Book Record REQ-3: Book entry REQ-4: Book issue REQ-5: Register student/staff Table 6.1: Requirement Matrix Table Requirement ID Technical Assumption(s) and/or Customer Need(s) Functional Requirement Status From Requirement To Requirement REQ-1: Student module to accept received books Book receive Essential  REQ-5   REQ-2: Record book transactions borrowed and returned Book Record Essential REQ-4 REQ-3: Record new library books Book entry Essential   REQ-4: Record books issued to user Book Issue Essential REQ-2 REQ-5: Register new users Register Students/Staff Essential   REQ-1 7. The Envisaged System The system being looked at will help streamline the borrowing and returning operations of the library. The Library staff will be able to check quickly if a lost book is overdue and to whom the lease belonged. The will further be able to realize the most requested books and will have a means of guiding the type and subjects of books that are most in demand by the users of the library. The system envisages that occasionally; the system will require specialized maintenance and the establishment of accounts levels within the system will ensure that the administrators already have the privileges they require for this work without the need to take the system offline. The envisaged alert system will ensure that forgetful students will get alerts reminding them whenever they get their books overdue. They will also get the ability through their accounts to know which books they borrowed and should they want to extend their lease they get to do so from the comfort of their accounts. They also get the ability to reserve books from their accounts. The higher degree students get to enjoy a seamless use of their privileges of borrowing more books than their juniors as well as being able to request books from public libraries. This is all possible from their accounts. Staff account can borrow books and also reserve books using their credentials. If their books become overdue, they have the privilege of automatically debiting their fines onto their payroll system on the HR system. They also can request for books from public libraries. 8. Does the document pass requirements review? The following crucial items are assessed to answer the question above; Verifiability. Is the requirement as stated realistically testable? Yes Comprehensibility. Do the end-users of the system correctly understand the requirement? Yes Traceability. Is the origin of the requirement explicitly stated? Yes. Sufficient information is given to the source of the requirements. Adaptability That is, can the requirement be changed without large-scale effects on other system requirements? Yes. Therefore; this document passes requirements review. Glossary MULS Macquarie University Library System SRS Software Requirement Specification LMS Library Management System IOS Apple’s software System Read More