Scribd
Upload
18 views

Classroom Activity

Classroom Activity

Uploaded by

James Leonard Munez
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views

Classroom Activity

Classroom Activity

Uploaded by

James Leonard Munez
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Classroom Activity: Case Study on Requirements Gathering and Analysis for a Book Monitoring

System
1. Stakeholder Interview
Key Questions
• For Students:
1. How do you currently search for books in the library, and what improvements would you
like in the process?
2. How often do you need to renew book loans, and would you prefer an automated
notification for due dates?
3. Would you prefer to borrow and return books through an online platform or in person?
4. What kind of history or records (e.g., borrowed books, due dates) would you want access
to?
5. What devices (laptops, smartphones) do you typically use to access library systems?
• For Librarians:
1. How do you manage book inventory, and what challenges do you face with the current
process?
2. How would you like to track book loans and overdue books more efficiently?
3. What features would help streamline processing book returns?
4. How often do you need to generate reports (e.g., for overdue books), and what data do you
require?
5. How important is user-friendliness in the system for your daily operations?
• For Library Administrators:
1. What kind of user roles would you like to manage (e.g., students, librarians, guest users)?
2. How do you ensure the security and privacy of user and inventory data currently?
3. What statistics or performance metrics would you like the system to generate?
4. How do you plan to oversee the maintenance of the system (e.g., user updates, book
inventory management)?
5. What are the top concerns you have for data backup, recovery, and overall system
performance?
Potential Challenges
• Misalignment in expectations between different stakeholder groups (e.g., students might prioritize
user-friendliness, while administrators focus on security).
• Difficulty in extracting specific, actionable requirements from vague or broad responses.
• Conflicting priorities or needs from stakeholders, such as librarians needing complex tracking,
while students prefer a simple interface.
• Time constraints or unavailability of stakeholders for interviews.
• Resistance to change from stakeholders accustomed to existing processes.

2. Requirement Analysis
Functional Requirements (based on interviews):
• Students:
o Ability to search for available books by title, author, or subject.
o Borrow, renew, and reserve books online.
o Receive automated notifications for due dates and overdue books.
• Librarians:
o Manage book inventory (add new books, update existing records, and remove outdated
materials).
o Track and manage book loans, including processing returns.
o Generate reports for overdue books and other loan-related metrics.
• Library Administrators:
o Manage user roles and permissions for students and librarians.
o Monitor inventory statistics and library activity (loans, returns, overdue notices).
o Ensure data security and system performance metrics.
Non-Functional Requirements:
• Performance: The system must handle up to 1,000 concurrent users with minimal latency.
• Security: User data and inventory records must be protected via encryption and role-based access
control.
• Usability: The system must be user-friendly and accessible via web browsers and mobile devices.
• Scalability: The system should support future upgrades to handle an expanding inventory and user
base.
MoSCoW Method Prioritization:
• Must Have:
o Ability for students to search and borrow books.
o Book loan tracking for librarians.
o Data security and role-based access control for administrators.
• Should Have:
o Automated reminders for overdue books.
o Generation of detailed inventory and loan reports.
• Could Have:
o Integration with other university systems (e.g., student portals).
o Mobile app for easy access to the system.
• Won’t Have:
o Support for external library databases in the initial version (may come in later versions).

3. Creating the Requirement Specification


3.1 Introduction
• Purpose: The Book Monitoring System will facilitate efficient management of library inventory,
book loans, and returns while enhancing user experience for students, librarians, and
administrators.
• Scope: The system will enable searching for books, managing loans, sending reminders, and
generating reports for the university library. It will include web-based access for all users and
integrate secure data management practices.
• Definitions:
o Book Monitoring System (BMS): The software system used for managing book
inventory, loans, and returns.
o Stakeholders: Individuals or groups that have an interest in the system (students,
librarians, administrators).
3.2 Stakeholders
• Students: Primary users who will search, borrow, renew, and receive notifications about books.
• Librarians: Managers of the book inventory and loan processes.
• Library Administrators: Supervisors overseeing system performance, security, and user
management.
3.3 Functional Requirements
• Students must be able to:
o Search books using various filters (e.g., title, author, genre).
o Borrow and return books either in person or online.
o Renew books and receive reminders via email for due dates.
• Librarians must be able to:
o Manage book inventory (add, update, or remove records).
o Process book loans, renewals, and returns.
o Generate overdue notices and reports of book loans.
• Library Administrators must be able to:
o Manage user roles and permissions.
o Monitor and generate reports on book inventory and library usage.
o Ensure data security (e.g., encryption, access control).
3.4 Non-Functional Requirements
• Performance: The system should support up to 1,000 concurrent users with response times under
2 seconds for key operations.
• Security: User data must be encrypted, and access must be restricted based on roles (students,
librarians, administrators).
• Usability: The system must be intuitive and accessible on desktops, tablets, and mobile devices.
• Scalability: The system must support future expansion in both the number of users and the book
inventory.
3.5 Assumptions and Dependencies
• The system will be web-based and accessible through standard browsers.
• Integration with existing university systems (e.g., student databases) will not be required in the
initial phase.
• The system will rely on an internal server for data storage and management.

4. Review and Feedback


• Present the requirement specification to the peer group or class for feedback on its completeness
and clarity.
• Revise the document based on feedback, focusing on areas such as:
o Improving clarity in functional requirements.
o Revisiting the prioritization of features (using MoSCoW).
o Addressing any overlooked non-functional requirements (e.g., backup procedures).

Members:
Diocampo, Nino Ariel
Flores, Justine Marc
Munez, James Leonard
Osma, Pius
Otarra, Ahnnia

You might also like