1MEIC04T01: RRBuddy - FEUP-MEIC-DS-2024-25/ai4sd GitHub Wiki

RRBuddy streamlines the requirements classification process and integrates with Gemini and Chat GPT. It automates report generation using a design template and supports requirements prioritization to aid in the decision-making process.

Vision

RRBuddy aims to revolutionize the requirements classification by offering an intelligent, automated solution that seamlessly integrates with Gemini and Chat GPT. The often time-consuming task of analyzing, categorizing, and reporting on requirements will be streamlined through intelligent automation.

Our platform will act as a focal point for product managers, developers, and stakeholders, providing them with a report of the requirements organized as Functional and Non-Functional, and between the Non-Functional the requirements will be classified as Performance, Scalability, Portability, Compatibility, Reliability, Maintainability, Availability, Security, Usability.

With its prioritization feature, teams can focus on high-impact tasks, enhancing project timelines and aligning efforts with strategic objectives for improved outcomes. Also, our AI assistant will generate a report outlining project requirements, providing all team members with essential information to streamline decision-making.

Ultimately, RRBuddy will become an indispensable tool for teams looking to optimize their processes, with the potential for integration into a broader ecosystem of development tools. RRBuddy will develop over time with ongoing learning and feedback, offering ever more accurate and context-aware suggestions to promote success in the contemporary digital environment.

Research

We didn't uncover any products that were comparable to our project during our investigation, but we did come across some articles that examined the application of various models to categorize needs and assess the outcomes.

Nicolas Fafin, Camille Salinesi, and Abdelkarim El-Hajjami wrote a paper titled "Which AI Technique Is Better to Classify Requirements? In a study comparing SVM, LSTM, and ChatGPT, they discovered that while ChatGPT produced superior overall results, these models shouldn't be utilized as a tool without human review because they performed poorly in determining which requirements solely possessed quality aspects.

In summary, linked research shown that models such as SVM, LSTM, and ChatGPT can help in classifying needs, even when no similar products were found.

Domain Analysis

Architecture and design

The architecture consists of four primary components, each fulfilling a specific role within the application:

  • Frontend: The frontend is the user interface, developed with React, and integrated with the AI4SD main platform. Through this interface, users can interact with RRBuddy, sending requests and customizing them to achieve the desired outcomes. The frontend offers an intuitive and responsive design, ensuring a smooth and efficient user experience.
  • Backend: The backend serves as the core of our project, handling all processing tasks except for the classification itself. In the event of scaling the application, the backend is the component that should be partitioned first, as many of its processes can be distributed across multiple servers.
  • LLM Endpoint: This is where the magic happens. Utilizing one of the supported Large Language Models (LLMs), and guided by the prompt engineered by the backend, the LLM classifies the document and returns the response to the backend.
  • Database: RRBuddy also includes a database for storing the history of user interactions, enabling a comprehensive record of all activities and facilitating future reference.

Sprint 1 Retrospective

During Sprint 1, we accomplished all the tasks we wanted during this sprint.

  • What went well?

    • What was possible to integrate with the general repository was done so effectively.
    • The preparatory work on the database structure for the next sprint was successfully completed.

  • What went wrong?

    • The team couldn't fully overcome the challenges related to integration.

  • What is still a problem?

    • Integration with the main project was not completed.

Sprint 1 Review

Sprint 2 Retrospective

During Sprint 2, we failed to accomplish to fully implement some tasks we proposed to this sprint related to integration.

  • What went well?

    • We successfully implemented most of the features planned which add value to the product.
    • We began the development of a filter system template that will be proposed for adoption to other groups in the future.
    • We began the development of the communication with the necessary google cloud components.

  • What went wrong?

    • The team couldn't get around the integration adversities every team faced in time.

  • What is still a problem?

    • Integration with the main project was not completed.

Sprint 2 Review

Sprint 3 Planning

Sprint 3 Retrospective

During Sprint 3, we finally completed the integration with the cloud.

  • What went well?

    • The team dealt well with pressure during this final sprint.
    • The team was even more united than usual.
    • The team started developing and contributing to the project common components.

  • What went wrong?

    • The team failed to estimate the workload of some backlog items.

  • What is still a problem?

    • No pressing issues.

Sprint 3 Review

Technologies

Client-Imposed Restrictions

  • React: The client required the frontend to be implemented using React. This decision is motivated by React's popularity, and by the central user interface all the apps need to have.

Our Choices

  • Python: We chose Python for the backend due to its simplicity and extensive library, which allows for rapid development and easy maintenance.
  • Flask: Flask was selected as the web framework for the backend because of its lightweight nature and flexibility. It enables quick setup and is ideal for small to medium-sized applications.
  • LLM Endpoints (ChatGPT and Gemini): For our LLMs we decided to use both ChatGPT and Gemini. This was decided based on both available free plans.
  • SQLite: Initially chosen for its simplicity and ease of setup, SQLite serves as a suitable database for development and testing purposes. If a more robust solution is required for production, we can switch to PostgreSQL, which offers advanced features, scalability, and better support for concurrent transactions.

Prototype and Base Implementation

Sprint 0 Implementation

During Sprint 0, we focused on creating a foundational prototype to validate the core functionality and integration of the system. The prototype included:

  1. Frontend-Backend Connection: We established a connection between an HTML frontend and a Python Flask backend. This setup demonstrated the basic communication flow between the user interface and the server.
  2. LLM Integration: The Flask backend was configured to communicate with the Gemini language model. This involved sending user inputs from the frontend to the backend, processing the inputs using the Gemini model, and returning the generated responses to the frontend.

Development guide

Explain what a new developer to the project should know in order to develop the system, including who to build, run and test it in a development environment.

Document any APIs, formats and protocols needed for development (but don't forget that public APIs should also be accessible from the "How to use" above).

Describe coding conventions and other guidelines adopted by the team(s).

Security concerns

Identify potential security vulnerabilities classes and explain what the team has done to mitigate them.

Quality assurance

Describe which tools are used for quality assurance and link to relevant resources. Namely, provide access to reports for coverage and mutation analysis, static analysis, and other tools that may be used for QA.

How to use

Explain how to use your tool from an user standpoint. This can include short videos, screenshots, or API documentation, depending on what makes sense for your particular software and target users. If needed, link to external resources or additional markdown files with further details (please add them to this wiki).

How to contribute

Explain what a new developer should know in order to develop the tool, including how to build, run and test it in a development environment.

Defer technical details to the technical documentation below, which should include information and decisions on architectural, design and technical aspects of the tool.

Contributions

Link to the factsheets of each team and of each team-member.