Database Diagram and Data Structure​

One of the main achievements of the week was preparing the database diagram for the new Maker Lab system. This helped us define the core entities of the platform and the relationships between them, including users, projects, project members, equipment models, equipment requests, request items, equipment usage, status history, and notifications.

Designing this structure was an important step because it made the system architecture much more concrete. It also helped us organize how project data, requisitions, and equipment assignments will be stored in a consistent and queryable way.

Frontend Development​

We also continued the frontend work on the platform. This stage focused on gradually turning the earlier mock-ups and requirements into actual interface elements that will support the main user workflows.

At this point, the frontend is becoming a more practical representation of the system we described in the previous milestone. This is especially important for features such as project creation, viewing project data, and handling requisition-related interactions in a clearer and more user-friendly way.

Technical Report​

Another major task this week was writing the technical report. The report consolidates the most important results of the project so far, including the project context, goals, selected technologies, requirements, architecture, and expected outcomes.

Preparing this document was useful not only as a formal deliverable, but also as a way to organize the project into one coherent technical vision. It helped us connect the requirements, the architectural decisions, and the implementation work already completed.

Click here to read our technical report!

VM, Database, and Snipe-IT Configuration​

This week was also important from the infrastructure point of view. We completed the virtual machine configuration and finalized the setup of the main backend environment. This included preparing the PostgreSQL database, creating scripts for table creation, and ensuring that Snipe-IT is running correctly in the target environment.

This was a significant milestone because it means that the project now has a real deployment base instead of being limited to local development only. With the database and inventory system running in the VM, the integration work can move forward on top of a working environment.

Why This Week Mattered​

This week was important because it moved the project from architectural planning into a more implementation-oriented stage. The database diagram clarified the system structure, the frontend work pushed the interface further, the technical report consolidated the project vision, and the VM setup established the real technical environment for deployment and integration.

Together, these results show that the project is progressing from concept and analysis toward a working system.

Next Steps​

In the coming days, we plan to continue connecting the frontend with the backend, expand the requisition workflow implementation, and move further with the integration between the application database and Snipe-IT.

Milestone 2 Presentation​

A major part of the week was dedicated to preparing the Milestone 2 presentation. During it, we presented the current state of the DETI Maker Lab project, summarized the most important requirements, and explained the proposed system architecture. We also showed the progress already achieved so far.

This presentation was an important step because it helped us organize our work into one clear and consistent vision of the system.

Click here to see our second presentation!

Mock-ups and Use Case Diagram​

We also worked on mock-ups and the use case diagram. The mock-ups helped us better visualize how users will interact with the platform and how the main workflows should look in practice.

At the same time, the use case diagram allowed us to structure the most important interactions between users and the system, especially around project creation, equipment requisitions, approval, and returns.

These artifacts made the project more concrete and helped connect the requirements with the future implementation.

Why This Week Mattered​

This week was important because it allowed us to transform earlier analysis into more visual and presentation-ready results. Preparing the presentation, mock-ups, and use case diagram gave us a better understanding of the system and helped us communicate our solution more clearly.

Next Steps​

In the coming days, we plan to continue refining the architecture, improving the interface, and moving further toward a working proof of concept, including the integration with authentication, the database, and Snipe-IT.

Functional and Non-Functional Requirements​

A major part of our work was dedicated to defining the functional and non-functional requirements of the system.

On the functional side, we described what the system should actually do. This included features such as user authentication through the university SSO, role-based access control, assigning users to projects, and supporting the full equipment requisition workflow: request, approval or rejection, assignment, and return. We also specified that the system should support multiple requisitions during a project lifecycle and allow querying data such as active requisitions, overdue returns, and equipment assigned to projects.

On the non-functional side, we focused on qualities that the system must provide. We identified security, data integrity, maintainability, and acceptable response time as some of the most important aspects. These requirements are especially important because the platform is meant to be reliable, easy to evolve, and simple enough to use in an academic environment.

Actors Identification​

Another important task was defining the main actors of the system. This helped us better understand who will interact with the platform and what their goals are.

We identified three main actors:

• Students – the primary users who request equipment for their projects, track requisition status, and return borrowed items.
• Lab Technician – the person responsible for managing inventory, approving or rejecting requisitions, and assigning or receiving equipment.
• Student Supervisor – a stakeholder who mainly reviews project progress.

Defining these actors gave us a clearer picture of the system’s responsibilities and will help us later when refining use cases and user stories.

Deployment Diagram​

We also worked on the deployment diagram, which helped us visualize the high-level technical structure of the solution.

This was an important step because our project is not just about defining features, but also about designing a realistic and viable architecture. The deployment diagram allowed us to think about how the main system components communicate with one another, how the application integrates with external services such as authentication and inventory management, and how the solution can be deployed in practice.

This work gave us a better understanding of the technical dependencies of the project and helped confirm that the proposed architecture is feasible.

Why This Week Mattered​

Overall, this week was about turning ideas into structure. By defining requirements, identifying actors, and preparing the deployment view of the system, we made significant progress toward a more complete and better justified solution.

These results will also serve as an important basis for our next steps, including use cases, architecture refinement, and the implementation of the first working system components.

Next Steps​

In the coming days, we plan to continue refining the system design, expand the use case analysis, and move closer to a working proof of concept that demonstrates communication between the main components of the architecture.

A major focus this week was setting up our public face. We spent time developing and deploying our official project website, which you can now visit at https://deti-maker-lab.github.io/. Having a central hub is essential for keeping our documentation and updates organized.

The rest of the week was dedicated to brainstorming and planning. Since one of our main constraints is to preserve the installed base and "not reinvent the wheel" , we spent a lot of time thinking about how to seamlessly connect the existing infrastructure with the new features we want to introduce, like the Snipe-IT integration and the improved mobile apps. We are currently organizing our thoughts in our team notebook and setting up our task backlog to prepare for the heavy lifting ahead.

During the meeting, we took a deep dive into the current solution—a Wiki-based platform implemented back in 2018 by a previous group. While it has served the lab well, we identified several pain points that our project needs to solve:

• Complex workflows: The current equipment requisition process is too complex and inconvenient to handle.

• Data entry issues: Relying on Markdown for project creation leads to inconsistent data and slows everything down.

• Tracking difficulties: Because the system is cumbersome, usage drops, making equipment tracking harder than it should be.

To wrap up the week, we defined the expectations for our team—like integrating the Snipe-IT inventory system and replacing Markdown with form-based inputs. We also prepared and delivered our presentation describing Stage 1 of our work, which aligns with the "Inception" phase of our OpenUP methodology. It was a highly productive week, and we now have a clear vision of the problem statement!

Click here, to see our presentation!