1MEIC04T02: ReqToStory - FEUP-MEIC-DS-2024-25/ai4sd GitHub Wiki
Our assistant product, called ReqToStory, aims to convert requirements into user stories, thus automating this time-consuming task.
Vision
As the complexity of a project increases, the process of converting requirements into user stories becomes increasingly time-consuming and prone to human error. Our product assistant, called ReqToStory, is ready to help software developers with this task. ReqToStory will use the Gemini AI, large language model (LLM), combined with an information retrieval system to generate user stories from a list of requirements.
This task, when done manually, is quite time-consuming, so with this automation, developers will have more time to focus on other more complex and/or creative activities. In addition, the quality of user stories will improve because they will now be generated with a well-structured pattern, which means they will be more protected from human errors such as misinterpretation or miscommunication.
It will be a great pleasure for us to see ReqToStory’s success, as it will mean that the product that we developed has managed to make a positive contribution in an area that is also of interest of us, because we are also a future user.
Research
Here are examples of comparable projects, assessed based on their advantages and drawbacks when compared ReqToStory:
Jira
-
Pros: Jira's strong project management features make it popular among businesses. With plugins like user story mapping, it may be customised and adjusted to fit different workflows.
-
Cons: Jira is not free, and the price can increase if you install more plugins. In comparison to ReqToStory, which is more specialised for turning requirements into user stories, it is less user-friendly because it also takes a significant amount of time to setup.
IBM Engineering Requirements Management DOORS Next
-
Pros: DOORS Next is an excellent option for regulated sectors that need to adhere to tight regulations since it provides robust lifecycle management and good traceability.
-
Cons: It is not appropriate for use by individuals or small teams because it is costly, complicated, and primarily meant for use in large organisations. It is not as easy to use and accessible as ReqToStory.
Aqua AI
-
Pros: By using artificial intelligence to analyse requirements and generate user stories and test cases automatically, Aqua AI speeds up and improves efficiency of the process. Additionally, it provides integration with other platforms and technologies, increasing its adaptability in diverse settings.
-
Cons: Compared to ReqToStory, which is intended to be more user-friendly, Aqua AI might have a steeper learning curve for consumers due to its complexity. Furthermore, compared to ReqToStory's free option, Aqua AI's price strategy might not be as feasible for smaller teams or individual users.
ReqToStory is distinct from the other projects because it is optimised for the particular task of converting requirements into user stories, which makes it both effective and user-friendly. In contrast to the other tools, which are expensive, technical, or require a lot of setting, ReqToStory provides a free, user-friendly solution that works for both individual and business users. This eliminates the need for complicated setup or extra plugins and makes it suitable for a variety of use scenarios.
One possible disadvantage is that ReqToStory lacks the broader project management capabilities as larger, more complex systems because it is just concerned with converting requirements into user stories. Nonetheless, teams aiming to optimise the user story generation process will find it to be a perfect tool due to its primary focus and simplicity.
Domain Analysis
Conceptual data model
Sequence diagram
Architecture and design
The main risk lies in the information retrievability aspect, as we need to maintain files with relevant content, such as user story examples and guidelines for crafting effective user stories, and be able to use this knowledge to enhance our prompts.
Technologies
To achieve our goal of implementing a fully functional AI generator that converts requirements into user stories, we used various technologies. We would say that the most important and central technology is the use of the Gemini API, an AI assistant from Google. We chose Gemini primarily because it offers fewer limitations in its free plan compared to other alternatives. Additionally, after a thorough evaluation, we found that it could be seamlessly integrated into our system, making it an ideal choice for our needs.
The second most important technology we used is Docker, an open-source containerization service, to implement the application. It provides an easy and powerful way to run our tool in isolated environments, ensuring consistency across development, testing, and production.
Since we decided to develop a website, we also employed other technologies such as TypeScript to handle the frontend of the application, CSS to organize and style the user interface in a way that we believe makes the most sense, and HTML to structure the application's user interface. For the backend, we chose Python due to its simplicity and efficiency, which allowed us to quickly develop a robust and scalable application.
Since we need a database, we chose to use PostgreSQL. We consider it a good choice as it is a robust, flexible solution capable of handling large volumes of data, and it offers advanced features like ACID transactions and has a large support community. Additionally, it is a technology that all of us have experience working with
In Sprint 0, we developed a system prototype. We created a web page where the user can submit requirements that will be used to generate user stories. To do so, they have two options: manually enter the requirements in a text box or upload a file containing the list of requirements. This information is sent to the backend, where it is complemented with a text that describes what we expect to obtain from the LLM, including the format of the user stories and acceptance criteria, as well as the structure in which we expect the data to be organized. Finally, the LLM's response is displayed to the user through the interface.
Sprint 1 Retropective
Keep Doing
- Continue the strong collaboration and teamwork that allowed us to complete all user stories successfully.
- Maintain the focus and efficiency that ensured timely delivery of tasks.
- Preserve the organized approach that kept everyone aligned on goals and expectations.
Do Differently
- Experiment with new development methods, such as pair programming, to foster knowledge sharing and teamwork.
- Improve the assignment process for user stories. Instead of waiting for members to finish their current tasks before taking on new ones, introduce a more balanced allocation method to prevent overloading certain team members.
- Encourage a system that inspires all members to complete their tasks promptly while ensuring equitable distribution of workload.
General Insights
- The team's strong performance highlights the potential for continued success with effective collaboration and planning.
- Exploring new methods and refining processes will help the team sustain its momentum and adaptability as future challenges arise.
Sprint 2 Retrospective
What Went Well?
- Most of the planned features were successfully implemented, providing valuable additions to the product.
- Continue the strong collaboration and teamwork that allowed us to complete all user stories successfully.
What Went Wrong?
- Integration challenges, especially during the process of merging our repository with the main project repository, caused delays in completing some tasks.
- Despite our efforts, the team was unable to fully resolve the integration issues in time, which impacted the completion of certain user stories.
What Is Still a Problem?
- The integration with the main project repository remains unfinished. We need to streamline the merging process and tackle conflicts more efficiently to avoid similar roadblocks in upcoming sprints.
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. For example: