Mandatory Project

This document serves as the mandatory project for DM571. This project is mandatory and must be passed to attend the exam. You will find more requirements in this document.

Note

  • Deadline: 2025-12-02 23:59:59

Formal Requirements

The project must be passed to attend the oral exam. The final grade is primarily based on the oral exam, but the project can raise or lower the grade by one grade step.

The project should be done in groups, preferably of 4 people and not more than 5 people per group. The report must contain a section stating who wrote what part of the report.

The project will consist of three ‘parts’. Part one will cover how we structure our process, backlog, and initial release planning. Part two will cover the initial design of the Minimum Viable Product (MVP) and implementation of some of the system. Part three will cover extended testing and integration of the system with 3rd party systems.

Part two and part three will be based on the previous parts of the project. All parts of the project will be based on the same interview. Document all assumptions you make!

If you don’t comply with these requirements you will fail the project!

This project is a made up case, but will have a lot of resemblance to the real world.

Background And Vision

I’m so happy that you want to be a part of this start-up. We need to get the first product into the hands of our customers as soon as possible to help us become profitable and to making money.

I have managed to find our first client for our product. This first customer is super important to us, and is willing to buy the project if we can show good progress with a steady stream of deliverables.

Let us look at our product idea, in case you forgot: We want to build a system where employees can upload their receipts into and automatically categorize them, and then send them to the accounting department.

This of course needs to be an online service with a corresponding (mobile friendly) website and maybe at some point a dedicated app.

Interview with an Accountant

Carsten: Thank you so much for showing an interrest in our product! I am really stoked that you took the time out of your, I presume, busy calendar to talk to me! Can you maybe tell me a bit about yourself and the company you work for?

Accountant: My name is Mr. Accountant. I have worked within accounting for more than 10 years, and the last 3 years have been here in Gravia Moribunda (Henceforth called GM). GM is a distributor of pots and pans. We have a rather big group of travelling salesmen going from store to store to sell our products.

Carsten: I don’t think we can do anything about the Travelling Salesmen, but I would suggest you to talk to O(n)-time Solutions. They have a reakky promising heuristic in the making.

Accountant: Ha ha. I know. But the handling of receipts would be nice to address. Every salesman gets his or hers expenses reimbursed, and at the moment we are spending quite a lot of time handling these. Some send them via email, some by iMessage, some send them with the Postal Service and some only give them to us when they are in the office. This process is very time consuming for us, and makes it difficult for us to close a given month from a financial view because we might get some receipts after 2-3 months.

Carsten: How would you know this situation had improved?

Accountant: Hmm, that is a really good question! Let me think for a second.

I would know it has become better when we only get receipts in one channel. I don’t know if this should be email or a separate system. Emails is easy, but we are more than me handling the receipts and sometimes we end up handling the same receipts twice. Hence, it would be nice to have some kind of system that would show if the receipt had already been handled.

Carsten: Ok, is correct to say you would like a system that gives you a simple overview of the incomming receipts and wether or not they have been filed correctly?

Accountant: Yes, but we also need to make sure that everything is in order, hence we need to make sure that we have a picture of the actual receipt, the amount and time of the receipt together with the correct bank statement, to make sure that we only process payments that actually happened.

We also need to inform the submitter that they MUST keep the original receipt!

Carsten: Would it be OK if we talked to a couple of the salesmen to hear how they would like to submit receipts? And then maybe we can come up with a good way to make it easy for the salesmen, while at the same time automate as much as possible of the filing it afterwards?

Accountant: You are more than welcome to try, but they are not hourly paid, hence they do not earn anything when they are talking to you. But you are welcome to try to talk to some of them. I can give you a list of potential people to talk to.

Carsten: That would be really awesome! Thank you!

Accountant: I just got to think of something I forgot to mention. Some of the office staff is not allowed to approve these receipts, hence one person might submit it, another person handles it, but then a Manager must approve the receipt in the end. This is to prevent fraud. The Manager must NEVER approve their own requests. Ok, that was a bit messy explained… Salesman A submits 4 receipts, to Accountant B. Accountant B then makes sure everything seems to be in order, only valid things for reimbursement etc. It is then sent to the Manager M of Salesman A. Manager M then approves the expenses or declines the expense report asking for further details, or that they won’t cover the expenses. The last scenario is very rare!

I also think it would make sense to have some administrators that can help out Salesmens, Accountants and Managers if something is stuck.

Carsten: Phew, this just a bit more complicated. But I think I follow so far. Do you have any requirements for logging of data? Here I am also thinking with respect to GDPR and since we are dealing with money I think there might be some further papertrails we need to create. Right?

Accountant: In order to avoid fraud we need to know exactly who put what in what field and when. This might seem obsessive, but we need to inform people that it is also to protect them.

Carsten: Ok! Thank you for letting me know! I think I have something to go on now! I will take it to the Development Team and I’m pretty sure the Product we are developing will solve a lot of your problems.

Part 1: Preparing our Process

In the first part of the project, your group needs to make the necessary preparations for the first sprint(s).

The report must include:

  • A description and classification of the different stakeholders
  • A description and classification of the different users (End Users, Super Users, and System User)
    • Who will be the user base? What is in it for them?
    • Who will maintain the platform on a daily basis and offer support to end users?
    • Which internal and third party systems will interact with out system?
  • A prioritized backlog containing all found requirements, both functional and non-functional in a format of your choice
  • An discussion on how and why you choose to structure your backlog as you did

For all of the items above you must:

  • Document your decisions
  • Document your assumptions
  • Discuss your approach to the task and your solution of it
  • Include the outcome of the task either in the report or in an appendix

Part 2: Making our First Product Delivery

In this second part of the project we will start to focus on implementing our new system.

Flows in the System

To align inside the team, we have agreed to make a workshop to align on how the flows should be in the system.

You must provide UML Sequence Diagrams for each flow/User Goal, and one consolidated UML Class Diagram with all the identified Domain classes. Document your sequence diagrams and your classes.

  • Create and Submit Receipt for Approval
  • Approve Receipt

API For Mobile Apps

We have had a new meeting with the Accountant from GM. He would like to create apps for smartphones using an external company. Hence, we need to make an API specification for this. This must be documented using Swagger or Open API. In this first iteration we need to specify the following endpoints:

  • Fetch a list receipts
  • Fetch a lift approved receipts
  • Create a new receipt and upload of documents

All these endpoints needs to be secured using API Keys. The API must be on at least level 2 of the Richardson Maturity Scale.

You must document your design design decisions, why and how you came up with the input, output and models. You must provide the specification as an appendix in the report.

This is only about specification, not about implementing it!

In a real project, we would start to agree on the interface, before going to the implementation.

Implementation and Testing

We need to quickly get something to the hands of our users. For this we need to start the implementation as soon as possible. It is important that we get a system that is maintainable and of high quality.

You must implement a system capable of handling some of the requirements.

It should have at least the following functionality:

  • List Receipts (Both approved and Rejected)
  • Create Receipt
  • Approve Receipt
  • Reject Receipt
  • View Receipt
  • Create a User
  • List Users and their receipts

At least three classes must be tested and a unit test coverage report must be made and attached to the report. For the report discuss the coverage you have reached. Is the code tested sufficiently? Any spots that could require more unit testing?

You must provide the Cyclomatic Complexity of each method and class.

Documenting the Architecture

With the classes implemented you must document your architecture. For this you need to use the C4 Model and make Level 1, Level 2, and Level 3. Some questions to ask yourself and document the answers to are:

  • Is this a layered architecture? 1 layer? 2 layers? 3 layers?
  • Looking at the article by Renzel, what distributions patterns have you used, if any?
  • Does the architecture live up to the relevant Agile Principles ?
  • Would creating Level 4 from the C4 model provide value? What value would that be?

Extra Requirements

To keep the scope of this assignment reasonable it is accepted to store data in memory (HashMap, LinkedList, …) with no persistence. But you must document this and what consequences does that have.

User Interface

For this you have two options, either:

  • Implement a simple User Interface / Working Prototype and hook it up with your classes for at least one sequence / flow
  • Create a High-Fidelity Prototype for the User Interface for at least two sequences / flows

For the one you select you must document the decisions behind your User Interface. It is not required to provide pixel-perfect User Interfaces but sketch out the idea behind it.

  • Record a video showing your User Interface and how it works

Integrating With The Bank

In the interview we learned that they would like to integrate with the bank, rather sooner than later.

The process with the bank is in short: Authenticate, fetch list of payments, and then mark the relevant payments as either: “approved” or “fraud”, in their system and ours.

They have a development system set up we can use here: https://finance.lutzen.dk .

Here you must do the following: