The Product

Imagine you are leading the construction of a new apartment complex. To ensure an adequate building is made, an enormous amount of requirements need to be fulfilled. These requirements have to be made for multiple different aspects of the entire process. For instance, the building design, the safety concerns, the method of construction and regulations for the people working on it, to name a few. These requirements must be written without any ambiguity, be able to be properly measured and validated, and must hold to the FAIR principles: thus being Findable, Accessible, Interoperable and Reusable. Doing this manually takes a significant amount of time, resources and money. Our project aims to improve all these areas, by transforming requirements to a machine-readable standard using a Large Language Model (LLM). For this, a website has been created where the user can input a requirement, which the LLM will convert to linked JSON data. The output of the LLM is based on the SPEC ontology, designed by NEN as a machine-readable standard for requirements. This can be visualized as a graph, which is shown on the website. To ensure the requirement is properly written, an auditor processes the input text and flags any ambiguous word usage.

The Customer

Our client was Robert Matousek, designer of the SPEC ontology and founder of Specified.AI and Kweri. During the project, he was always very enthusiastic and open for improvements on his vision of the final result. Communication with him was swift, clear and informal yet professional. We arranged meetings with him each sprint review, refining the project goal as he provided different possibilities on how to continue. Overall, his feedback was clear and useful, although a bit chaotic, meaning we often had to significantly alter our tasks.

  • "Software engineering is not just about writing code. It's about solving problems and making lives better."
  • "Weeks of programming can save you hours of planning."
The Team

The team was very well-balanced. Three different majors were present in our team, meaning we had a wide selection of capabilities to work with. We divided the tasks in our project so that they are mostly independent of each other, and could be aligned to the strengths of each person. This ensured we did not have to waste much time when switching between tasks and having to pick up the pieces. The team came together twice per week, and put in good work every meeting. Our Git repository was managed by our Scrum master and product owner. They worked together to keep the repository clean and maintain the project board at all times. Doing this, the whole team could be up to date on the current sprint progress. All in all, we are very satisfied with our teamwork, and proud of our final product.

The Technologies