GenAI Usecase Illustration: Lost and Found Application Requirements

In this page, there are two prompts and the corresponding outputs. First a Prompt 1 is used. Subsequently, an Prompt 2 (Enhanced version of Prompt 1) is used. Both the prompts and their corresponding outputs are shown below.

Prompt 1

Generate requirements (business requirements, stakeholder requirements, functional requirements (as user stories), non-functional user stories and transition requirements for the following system:

A Lost and Found system in a business management institute where all programs are offered with students in the campus.

Output1 (Prompt 1 output)

Okay, this is a great system to define requirements for! Here’s a breakdown of the requirements for a Lost and Found System in a business management institute with students on campus:

Lost and Found System Requirements

System Name: Institute Lost and Found Management System (ILFMS)

Primary Purpose: To efficiently manage lost and found items within the business management institute, facilitating the swift return of items to their rightful owners and maintaining a clear record of all reported and recovered items.

Main Users/Stakeholders:

  • Students: Primary users who lose items or find items.
  • Institute Staff (General): Staff members who might find items or guide students.
  • Administrative Staff (Lost & Found Custodians): Dedicated staff responsible for managing the Lost & Found inventory, verifying ownership, and facilitating returns.
  • Security Staff: May be involved in initial collection of found items or guiding individuals.
  • Institute Management: Overseeing the efficiency and effectiveness of campus operations.

Key Features Envisioned:

  • Reporting lost items online.
  • Reporting found items online.
  • Searching for lost items by description.
  • Matching found items to lost reports.
  • Notification system for matched items.
  • Item collection process with verification.
  • Inventory management for found items.

1. Business Requirements

These describe the high-level goals and objectives for the institute regarding the Lost and Found System.

  • BR1: Improve Item Recovery Rate: The system shall increase the successful return rate of lost items to their owners by at least 30% within the first year of operation.
  • BR2: Enhance User Satisfaction: The system shall improve student and staff satisfaction with the Lost and Found process, measured by a 20% increase in positive feedback on the efficiency and ease of item recovery.
  • BR3: Streamline Operations: The system shall reduce the administrative overhead for managing lost and found items by at least 25%, freeing up staff time for other core activities.
  • BR4: Ensure Accountability & Transparency: The system shall provide a clear audit trail and record of all lost, found, and returned items to ensure accountability and transparency in the process.
  • BR5: Reduce Institute Liability: The system shall minimize potential disputes or claims related to lost items by establishing a clear, documented process for handling items.

2. Stakeholder Requirements

These describe the specific needs and expectations of various stakeholder groups.

  • SR1 (Students): As a student, I need to easily report a lost item so that I can maximize my chances of getting it back quickly.
  • SR2 (Students): As a student, I need to easily report an item I found so that I can help return it to its owner and contribute to the campus community.
  • SR3 (Students): As a student, I need to be able to search for my lost item using various criteria (e.g., item type, location, date) so that I can quickly check if it has been found.
  • SR4 (Students): As a student who has reported a lost item, I need to be notified when an item matching my description is found so that I can arrange for its collection.
  • SR5 (Students): As a student, I need to understand the process for collecting a matched item so that I can retrieve it without confusion.
  • SR6 (Admin Staff/Custodians): As a Lost & Found custodian, I need to efficiently log newly found items with detailed descriptions and photos so that they can be easily matched with lost reports.
  • SR7 (Admin Staff/Custodians): As a Lost & Found custodian, I need to easily search and match reported lost items with found items so that I can facilitate returns.
  • SR8 (Admin Staff/Custodians): As a Lost & Found custodian, I need to manage the status of items (e.g., reported lost, found, matched, claimed, disposed) so that I have an accurate inventory.
  • SR9 (Admin Staff/Custodians): As a Lost & Found custodian, I need to communicate with students/staff regarding matched items and collection arrangements so that items are returned smoothly.
  • SR10 (Admin Staff/Custodians): As a Lost & Found custodian, I need to access historical data and reports on item types, recovery rates, and trends so that I can identify patterns and improve the service.
  • SR11 (Admin Staff/Custodians): As a Lost & Found custodian, I need to manage item disposal procedures for unclaimed items (e.g., donation, auction) so that storage space is managed effectively.
  • SR12 (Institute Staff – General): As an institute staff member, I need a clear process to report items I find so that they can be safely handed over to the Lost & Found department.
  • SR13 (Security Staff): As a security staff member, I need to quickly identify if an individual claiming an item is the rightful owner so that only authorized persons retrieve items.
  • SR14 (Institute Management): As institute management, I need a dashboard or reports to monitor the effectiveness and efficiency of the Lost and Found operations.

3. Functional Requirements (as User Stories)

These describe what the system does for its users, from their perspective.

As a Student:

  • FR1 (Report Lost Item): As a student, I want to report a lost item by providing details such as item type, description, brand, color, last seen location, and approximate date/time, so that the institute can help me find it.
  • FR2 (Upload Photo – Lost): As a student, I want to optionally upload a photo of my lost item so that it’s easier to identify.
  • FR3 (Provide Contact Info – Lost): As a student, I want to provide my contact information (e.g., email, phone number, student ID) when reporting a lost item so that I can be contacted if it’s found.
  • FR4 (Report Found Item): As a student, I want to report a found item by providing details such as item type, description, brand, color, where it was found, and approximate date/time, so that it can be returned to its owner.
  • FR5 (Upload Photo – Found): As a student, I want to optionally upload a photo of a found item so that it’s easier for the owner to identify.
  • FR6 (Search Lost Items): As a student, I want to search through a list of found items by applying filters such as item type, location found, and date found, so that I can see if my lost item is there.
  • FR7 (View Found Item Details): As a student, when I find a potentially matching item in the search results, I want to view its detailed description and photo so that I can confirm if it’s mine.
  • FR8 (Initiate Claim): As a student, when I find my item listed, I want to initiate a claim for it through the system so that the custodian is notified.
  • FR9 (Receive Match Notification): As a student, I want to receive an email or SMS notification when a found item matches my lost report so that I can arrange for collection.
  • FR10 (View Claim Status): As a student, I want to view the status of my claim (e.g., “Pending Verification,” “Ready for Pickup,” “Claimed”) so that I am informed about the process.

As Administrative Staff (Lost & Found Custodian):

  • FR11 (Log Found Item): As a custodian, I want to log a new found item, including detailed description, photos, location found, and date/time found, so that it’s accurately recorded in the inventory.
  • FR12 (Manage Item Details): As a custodian, I want to edit details of a logged item (lost or found) in case of errors or additional information so that the records are accurate.
  • FR13 (Match Items): As a custodian, I want to view potential matches between reported lost items and logged found items based on keywords and categories so that I can facilitate the matching process.
  • FR14 (Verify Ownership): As a custodian, I want to record verification details when an item is claimed (e.g., student ID check, security questions about the item) so that only the rightful owner retrieves it.
  • FR15 (Update Item Status): As a custodian, I want to update the status of an item (e.g., “Found,” “Matched,” “Claimed,” “Disposed”) so that the system reflects its current state.
  • FR16 (Generate Collection Instructions): As a custodian, I want to generate collection instructions for a matched item, including pickup location and required identification, so that the student knows how to retrieve it.
  • FR17 (Communicate with Claimants): As a custodian, I want to send system-generated notifications (email/SMS) to claimants regarding their item’s status or collection details.
  • FR18 (Manage Disposal): As a custodian, I want to mark items as “Disposed” (e.g., donated, auctioned, discarded) after a defined period if unclaimed so that storage is managed.
  • FR19 (View Dashboards/Reports): As a custodian, I want to view reports on total lost/found items, successful recovery rates, and common lost item types so that I can analyze trends.

As General Institute Staff / Security Staff:

  • FR20 (Submit Found Item): As general staff, I want a simplified interface to submit basic details of a found item (type, location found) and indicate where it was physically deposited (e.g., Security Office, Admin Desk) so that the custodian can formally log it.

4. Non-Functional Requirements (as User Stories)

These describe the quality attributes of the system.

Performance:

  • NFR1 (Search Response Time): As a user, I want search results for items to load within 3 seconds, even with 10,000 active items, so that I can quickly find what I’m looking for.
  • NFR2 (Reporting Latency): As a user, I want the system to process my lost or found item report within 1 second after submission so that I receive immediate confirmation.

Security:

  • NFR3 (Data Confidentiality): As an institute, we need to ensure that personal contact information (email, phone number) submitted by users is accessible only to authorized Lost & Found custodians, so that privacy is maintained.
  • NFR4 (Access Control): As an institute, we need the system to support role-based access control, so that students can only view public information and manage their own reports, while custodians have full management access.
  • NFR5 (Authentication): As a user, I want to log in using my institute credentials (SSO if available) so that my identity is verified and no unauthorized access occurs.
  • NFR6 (Data Integrity): As an institute, we need the system to protect against unauthorized modification or deletion of item records so that the inventory remains accurate and reliable.

Usability:

  • NFR7 (Intuitive Interface): As a user, I want the system interface to be intuitive and easy to navigate with minimal training so that I can quickly report or search for items.
  • NFR8 (Mobile Responsiveness): As a student, I want to access and use the Lost and Found system effectively on my mobile phone so that I can report or search for items from anywhere on campus.
  • NFR9 (Clear Instructions): As a user, I want clear instructions on how to report, search, claim, and collect items so that I understand the entire process.

Reliability:

  • NFR10 (System Uptime): As an institute, we need the system to be available 99.5% of the time during business hours (7 AM – 7 PM, Monday-Saturday) so that students and staff can always access it.
  • NFR11 (Data Backup): As an institute, we need the system to have automated daily backups of all data so that lost data can be recovered in case of system failure.

Maintainability:

  • NFR12 (Code Modularity): As a development team, we want the system’s code to be modular and well-documented so that future enhancements and bug fixes can be implemented efficiently.
  • NFR13 (Logging & Monitoring): As an institute, we need the system to log errors and user activities so that issues can be diagnosed and system performance monitored.

Scalability:

  • NFR14 (User Load): As an institute, we need the system to support up to 5,000 concurrent users without significant performance degradation during peak times (e.g., beginning of semester) so that all students can access it.
  • NFR15 (Item Volume): As an institute, we need the system to efficiently handle up to 20,000 item records so that it can accommodate growth over several years.

5. Transition Requirements

These describe the conditions needed to facilitate the successful deployment and adoption of the new system.

  • TR1 (Data Migration): The system shall support the migration of any existing Lost and Found records (if applicable, e.g., from spreadsheets or manual logs) into the new system format before launch.
  • TR2 (User Training Materials): Comprehensive training materials (e.g., user manuals, quick guides, FAQs, video tutorials) shall be developed for students and administrative staff before system launch.
  • TR3 (Administrative Staff Training): Dedicated training sessions shall be conducted for all Lost & Found custodians and relevant administrative staff on how to use and manage the system effectively.
  • TR4 (Communication Plan): A communication plan shall be developed and executed to inform all students and staff about the new system’s launch, its benefits, and how to use it.
  • TR5 (Old Process Decommissioning): Clear guidelines shall be established for the phased decommissioning of the old Lost & Found process (if any) to ensure a smooth transition.
  • TR6 (Support Structure): A support structure (e.g., help desk, dedicated contact person) shall be in place to address user queries and technical issues immediately after launch.
  • TR7 (Physical Item Handling Procedures): Revised and documented physical procedures for handling found items (where to drop off, initial tagging) and claiming items shall be disseminated to all relevant staff.
  • TR8 (System Access Setup): The system shall be integrated with the institute’s existing user authentication system (e.g., LDAP or SSO) to facilitate seamless login for students and staff.

Prompt 2: Enhanced Prompt

You are a Business Analyst tasked with defining the complete requirements for a Lost and Found System for a campus-based Business Management Institute. The system must support all academic programs and facilitate interactions between students, staff, and administration.

Your response must be structured using the following specific headings and formats:

1. Business Requirements (High-Level Goals)

  • Format: List 3-5 measurable, high-level business objectives this system must achieve. (e.g., Reduce time spent by staff on manual lost item inquiries).

2. Stakeholder Requirements (Needs by Group)

  • Format: List 2-3 specific needs for the following key stakeholders:
    • Students (Item owners and finders)
    • Staff/Faculty (Potential finders)
    • Campus Administration (Oversight and reporting)

3. Functional Requirements (User Stories)

  • Format: Provide at least eight (8) detailed user stories, covering the primary functions of Reporting, Claiming, and Tracking. Use the standard template: “As a [Role], I want to [Goal] so that [Reason/Benefit].”

4. Non-Functional Requirements (User Stories)

  • Format: Provide at least four (4) non-functional user stories (or statements) focusing on the Performance, Security, Usability, and Availability attributes of the system.

5. Transition Requirements

  • Format: List 2-3 key requirements needed to migrate from the current manual process (assume paper logs and email) to the new digital system. (e.g., Training, Data Migration).

Output of Prompt 2 (the Enhanced Prompt)

Below is a complete, well-structured Business Requirements Document (BRD) for a Campus Lost & Found System following exactly the format you requested.

1. Business Requirements (High-Level Goals)

  1. Reduce the average time to report or claim a lost item by 50% through a centralized digital platform.
  2. Increase successful return of lost items by at least 40% with structured tracking and notifications.
  3. Minimize manual workload for administrative staff by 60% by digitizing logging, verification, and status updates.
  4. Provide real-time visibility and auditability of all lost and found records for compliance and campus operations.
  5. Improve communication efficiency between students, faculty, and administration regarding lost items.

2. Stakeholder Requirements (Needs by Group)

Students (Item Owners and Finders)

  1. Ability to quickly report a lost or found item using mobile or web.
  2. Ability to search and filter items to identify matches easily.
  3. Receive notifications about status updates, potential matches, and claim approvals.

Staff / Faculty (Potential Finders & Verifiers)

  1. Ability to log found items from classrooms, labs, and common areas.
  2. Ability to verify ownership claims based on submitted evidence.
  3. Access to item status updates (claimed, pending verification, unclaimed).

Campus Administration (Oversight & Reporting)

  1. Ability to generate reports on item trends, volume, and resolution rates.
  2. Ability to manage categories, campus zones, and system-level configurations.
  3. Tools to ensure compliance, audit trails, and data integrity.

3. Functional Requirements (User Stories)

Reporting Lost Items

  1. As a Student, I want to report a lost item with a description and photos so that others can help identify it.
  2. As a Student, I want to specify the date, location, and category of the lost item so that the system can match it effectively.

Reporting Found Items

  1. As a Staff/Student, I want to log a found item and drop it at a designated counter so that the owner can retrieve it.
  2. As a Staff member, I want to attach storage location details to a found item so that the admin team knows where the item is kept.

Claiming Items

  1. As a Student, I want to claim an item by submitting proof of ownership so that the admin can verify and release it to me.
  2. As an Administrator, I want to review claim submissions and approve or reject them so that the right owner receives the item.

Searching & Notifications

  1. As a Student, I want to search for lost or found items using keywords, category filters, and date range so that I can quickly identify matches.
  2. As a Student, I want to receive automatic notifications when new items match my lost-item report so that I can take action quickly.

Tracking & Administration

  1. As an Administrator, I want to update the status of an item (e.g., received, verified, claimed, disposed) so that records remain accurate.
  2. As Campus Administration, I want to export data on items and claims so that reporting can be done for audits.

4. Non-Functional Requirements (User Stories)

Performance

  1. As a User, I want the system to load item listings within 3 seconds so that I can search efficiently.

Security

  1. As Campus Administration, I want all user data and item images to be securely stored and accessible only through authenticated login so that privacy is protected.

Usability

  1. As a Student, I want a mobile-friendly interface so that I can report or check item status on the go.

Availability

  1. As a Staff member, I want the system to be available 99% of the time during academic hours so that I can log found items without delays.

5. Transition Requirements

  1. Training & Onboarding: Conduct training sessions for administrative staff, faculty, and student representatives to adopt the new system.
  2. Data Migration: Digitize existing paper-based lost/found logs and migrate them into the new system for continuity.
  3. Change Management: Communicate new procedures, designated drop-off points, and system usage guidelines to all campus stakeholders.