Crafting Clear Paths: A Comprehensive Guide to Defining Requirements for Your Web Application Project

Turns out step one isn’t just step one.

My ChatGPT Prompt

How do I do Step One: Define Requirements

ChatGPT Response

Defining requirements is a crucial step in the project development process, and it involves gathering, documenting, and understanding what your stakeholders (in this case, the guild librarian) need from the web application. Here’s a guide on how to approach this:

  1. Identify Stakeholders:
    • Determine who the key stakeholders are. In this case, it’s likely the guild librarian, but there may be other individuals or groups with a vested interest in the project.
  2. Hold Stakeholder Meetings:
    • Schedule meetings with the stakeholders to discuss the project. During these meetings, ask open-ended questions to encourage discussions about their needs, expectations, and any specific functionalities they envision.
  3. Ask Specific Questions:
    • To gather detailed information, ask specific questions about the equipment tracking system. For example:
      • What types of equipment does the guild have?
      • What information needs to be tracked for each piece of equipment?
      • How should the system handle check-in and check-out processes?
      • Are there specific reports or notifications that would be helpful?
  4. Document Requirements:
    • Document all the information gathered in a structured manner. Create a Requirements Document or use a tool like Confluence, Google Docs, or even a simple spreadsheet. Ensure that the document is clear and accessible to all team members.
  5. Clarify Priorities:
    • Work with the stakeholders to prioritize the identified requirements. This will help you focus on the most critical features and functionalities, especially if there are time or resource constraints.
  6. Verify and Validate Requirements:
    • Once you have a draft of the requirements, go back to the stakeholders to verify and validate the information. This ensures that you’ve captured their needs accurately and haven’t missed anything.
  7. Consider Edge Cases:
    • Think about potential edge cases or scenarios that might not have been explicitly mentioned. Anticipate challenges or exceptions that could occur in real-world usage.
  8. Iterate as Necessary:
    • Requirements gathering is an iterative process. Be prepared to revisit and update the requirements document as the project progresses and new insights emerge.
  9. Create User Stories:
    • Based on the requirements, start creating user stories. User stories represent specific functionalities from an end-user perspective and will be useful when you set up your project management system.
  10. Communicate Clearly:
    • Ensure effective communication between the development team and stakeholders. Clearly articulate what is feasible within the project scope and timeline.

By following these steps, you’ll establish a solid foundation for your project, ensuring that you have a clear understanding of what needs to be built and how it aligns with the expectations of the guild librarian and other stakeholders.

The Results

I have already collected some of the information already. So this is the inventory of what I have, what I think I know, and what I need to follow-up on.

Identify Stakeholders: This is indeed pretty straight forward. The main stakeholder is going to be the guild librarian, but I also want to include the guild’s membership because they are going to be the ones that actually initiate the check-out process.

Hold Stakeholder Meetings: This step is a little over kill for our little group. We only have about 55 members. During a previous meeting with the librarian I feel like we already completed this step. Follow-up meetings will probably need to happen, at least to demonstrate what’s been done in the development and to present my approach to finding the solution that works best for our needs.

Ask Specific Questions:

  • What types of equipment does the guild have? We already have an inventory of the equipment. It includes looms, spinning wheels, and other tools.
  • What information needs to be tracked for each piece of equipment?
    • Where the item is stored?
    • What is Its status?
    • Who has it checked-out if it is checked-out?
    • Is there someone on the waitlist for the equipment?
    • When is it expected to be checked-in?
  • How should the system handle check-in and check-out processes?
    • –> I had to ask a follow up question on this one because this sounded a little vague to me. ChatGPT came back with the following:
      • User Interaction: Through a web form
      • Equipment Identification: Each piece of equipment has a unique serial number (SN)
      • Transaction Logging: Collection of data such as the equipment SN, when it was checked out and to whom.
      • Notification System: Several notifications will be generated for each check-out/in
      • Reservation/Waitlist System: I will need to follow up on the reservation system, but there will need to have a waitlist for items.
      • Overdue Alerts: Lending time is 30-days, but can be re-checked out if there is no waitlist.
      • Access Controls: Only guild members should have access.
      • Integration with Database: The DB should be updated whenever equipment is checked-out/in
  • Are there specific reports or notifications that would be helpful?
    • Yes, the librarian needs to be alerted when the equipment is returned and if the item has a waitlist, the next user is notified that the item is available. 30-Day Check-out renewal sent if no waitlist, otherwise a notification that the item needs to be returned because there is a waitlist.

Document Requirements: Since I already have the project setup with JIRA I will use Confluence to document what those requirements are.

Clarify Priorities: The most important feature for the librarian is to be able to accurately and easily track the check-in of the equipment. There are several other features that need to be developed that will be transparent to the end-users. The stakeholders just want the ability, they are not expecting an iterative process.

Verify and Validate Requirements: Need to do

Consider Edge Cases: The system is pretty straight forward, but some of the other things I can see needing:

  • A way for the members to check the status of the equipment
  • A way to submit a query about the equipment or about the process

Iterate as Necessary: Self-explanatory

Create User Stories: Need to do

Communicate Clearly: Need to create a regular update schedule to let the librarian and officers know the project’s progress.

Next Step(s)

Clearly, I’m going to need to do some documentation and go back to communicate my assumptions with the stakeholders to ensure I’m going in the right direction. I need to add to Confluence and JIRA to track what I’ve been working on and my work with the stakeholders.


Submit Feedback