I worked with five other students to develop a storage management system for the NTU stores. First we had to figure out the requirements and specify the system. To better understand the problem, we had a site visit to the stores and carried out field research. This was followed by brainstorming, role playing, and process analysis. We wrote a Requirements Specification. In this we stated the purpose of the project, researched existing solutions, examined the user characteristics, and interviewed potential users of the software. We described the assumptions that we were making, set the scope and constraints, and created a glossary of terms. We then created lists of Functional and Non-Functional Requirements (which continued to change throughout the project). The FRs and NFRs were all rated as either must, should, could, or won't.

We drew up interface diagrams to show how the software will be accessed by users and interact with external systems. It needed to be able to be accessed through desktops and laptops as well as mobile devices. It would also need to consume external REST APIs as well as be able to be consumed by external services, so that it could be built upon in the future.

We used use case modelling to explore the different situations within which our software would be used, and to understand these use cases. We drew a table of use cases, and a use and misuse case diagram. We looked at how bad actors could misuse certain features of the system and how we should preemptively guard against misuse. In this project, we used the Agile methodology - we held stand up and sprint meetings. Unfortunately, these were not as frequent as they should have been, because we all had other modules to be working on, had to work on other things at same time.

The software itself has two main components. One was the web service REST API, and one was the Angular Client. The Angular Client was designed mobile first, but it scales well for different screen sizes - it works nicely on the desktop as well. For the REST API, we separated it into layers. The service layer, which defines the REST API interface, was kept separate from the business logic, and from the data access layer. These different components could be switched out and upgraded or changed individually, without affecting the others. We used a MySQL database, because the team was already familiar with it. We did plan to interface with the QuickBooks external REST API, but due to time constraints, we didn't get around to that.

We developed quite a good looking Angular app, which was made in pretty much the last week and a half. We had some custom logos, things like the checkout button, which was a nice touch.

The actual software has two kind of main user modes: the customer interface, and the staff interface. The customer can only view their current basket, add items to it, and checkout the basket. They add items to their basket by scanning the barcodes or by adding them manually. When they checkout the transaction, they input their ID and their budget code. In the staff mode, staff can edit existing transactions, refund transcations, and manage the products database.

What did I learn from the group project?

I learned that it is easier to get people to agree to doing a task, than it is to actually get them to do the task. And also that sometimes it can be a lot easier to do it yourself. This can be prevented by making sure that everyone is on board with the objectives, and then defining the tasks together as a team. The more choices people make for themselves, the more autonomous they are, the happier they will be with doing their work. It can get difficult if people just don't take part. Fortunately most of my team was very well motivated.

Shared ownership encourages enthusiastic cooperation!

What did I find in terms of technology?

I wouldn't use Spring again, and I'm no longer such a fan of Java after this experience. My insistence on using dependency inversion to separate concerns actually overcomplicated things, and reduced the extent to which others in the group could take ownership of their work. In retrospect, splitting the product vertically instead of horizontally may have been wiser. Three microservices: staff, products, and transactions. Splitting it out into microservices would have meant that we weren't waiting for each other quite so much, as the components were not orthogonal enough to allow us to work in parallel particularly well.

Some of the work we did do sitting in the same room, and working in that way we got a lot done very quickly. But a lot of work was done remotely. With remote working, a microservice like architecture has stronger advantages because it allows clear separation of concerns, and more autonomy in implementation.