Our website is a unique platform where students can share their papers in a matter of giving an example of the work to be done. If you find papers
matching your topic, you may use them only as an example of work. This is 100% legal. You may not submit downloaded papers as your own, that is cheating. Also you
should remember, that this work was alredy submitted once by a student who originally wrote it.
The paper "Application Modelling: Macquarie University Library System" is a great example of a report on management. A user-friendly environment for maintaining a catalog of books and member information is the primary reason for developing the Macquarie University Library System. MULS is a system to be used by the university’s library staff…
Download full paperFile format: .doc, available for editing
Extract of sample "Application Modelling: Macquarie University Library System"
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
Share:
sponsored ads
Save Your Time for More Important Things
Let us write or edit the report on your topic
"Application Modelling: Macquarie University Library System"
with a personal 20% discount.