Functional and non functional requirements

Our solution should fulfill both the functional and non-functional requirements adequately. The functional requirements are in this case the same as the user stories related to our Scrum-process. User stories are also sorted after sprint numbers and importance within the sprint.

Requirements

Due to changes during the project, some user stories are outdated (mentioned below). We did not restard ID-numbers when changing our backlog. Some user stories that continued to be valid kept the ID, while new user stories continued to increase from the highest number.

Functional requirements

Sprint	User Story #	Description
1	-	-
2	28	As a DP I want the API to support production data as input.
3	25	As a DG I want the system to gather, update and segment the road network and store it in the database.
	23	As a user of the system I want the production data to be correctly mapped to a road segment.
	27	As a DG I want to be able to retreive the attributes of a given road segment.
4	24	As a user I want the system to check if new production data belongs to a road with already existing production data
	29	As a DG I want to be able to see a guide and/or documentation for the api.
	31	As a user I want the system to be wrapped in a Docker container so that I easily can set up the project.
5	8	As a DG, I would like to see weather data on a given road segment.
Not included	4	As a DG, I want to specify which data attributes I want to gather from a given road segment.
Not included	26	As a DG I want to gather road segments in a given area.
Not included	30	As a DP, I want a UI to input production data.

Non-functional requirements

NFR #	Description
Testability	Provide tests for testing the product.
Documentation	It should be easy for users to understand and use our API when using our documentation
Extensibility	White-box extensibility, NPRA want the ability to edit the source code for further extensions.

To address these requirements we have done several measures.

Documentation

Since our customer is interested in using our product in further projects, they wanted the product to be easy to use. That includes that our system should be well documented for future developers so they manage to use the tool we have provided. To meet this demand we have created an API documentation page regarding the use of the system, Wiki page describing the project and this report describing our process. Our code are also well described with comments and self explanatory function and variable names.

We had our API guide and code reviewed by a potential future developer to see if how long time that was needed to understand the functionality we have provided. It should take no more than one work day (8 hours) to understand and use our tool.

Testability

Though we did not receive any specific demands to tests or testability by our customer, we made sure that most of our major functions are easy to test with unit tests. The tests in our product are mainly implemented based on our own sense of professionalism, by releasing a product with good test coverage and an easy way of implementing new tests down the line.

This would also provide valuable information to future developers when they continue the development, since the tests we provide will inform them if they make breaking changes.

Extensibility

We have implemented our system as a white-box, open-box for the continuous use of our system. With upgrades and extensions to VAPI the source code may need changes to handle either new data attributes or another data format. Our code base is modular and well documented for future developers to understand the product and continue to improve it.

This requirement is not really measurable, however we have developed a system with an architecture that should be possible to improve and extend for other developers.

Further development

While some non-functional requirements were requested by our customer, there are also other potential requirements for future development of the product that were not relevant for our project. The NPRA did not want us to release the product on a live website, so there are certain requirements tied to that which would need to be handled before a future release. The most relevant future features that we can think of are noted in the table below, and further described afterwards.

Non-functional requirements

NFR #	Description
Security	Standard database security and validation.
Performance	The performance needs to be good enough to be usable in the final product.
Usability	Documentation needs to be thorough so developers can learn the system quickly.
Maintainability and Scalability	Should be simple to change data input to comply with new requirements.

Security

We consider the security measures that already exists in django to be enough, mainly that users need different levels of clearance to use different functionalities (e.g. POST is locked behind the ADMIN user). The addition of another type of user is a security measure that should be implemented in the future, mainly because the ability to POST data could be desirable for the entrepreneurs that deliver the data.

Depending on which data fields that are added in the future, and eventually new functions containing confidential or valuable information security measures can be important. As of today we have standard database validation through PostgreSQL and user authentication with Django.

Performance

The biggest cause of bad performance, or our bottleneck, in VAPI is currently the map-matching and insertion of production data. Map-matching is now running through every segment in the database to find the closest one it can write the production data to. This results in a runtime of O(n), which in itself is decent, but the large amount of segments in our database makes it slow very fast. A possible fix to this could be that the map-matching only searches for segments within a given radius of the coordinates of the production data.

The initial segmentation could also be improved upon, but this is most likely a more complex improvement than the map-matching function.

Data integrity

While we have many tests that ensures that the API has the desired output with a given input, the overall integrity of the data from start to end are not checked enough. Tests that check the data every time it is converted, as well as checking start and end data, is something that will ensure higher data integrity.

Maintainability and Scalability

Roads are not in any constant state and new roads are continuously made. Adding fields to road segments and updating the road network is possible in our system. This is necessary for the product to handle changes to road structures in the future.

The main problem with scalability of the current API is its performance with a larger database. An upscaled amount of GET-requests should not be a problem, but the POST-request and the functionality of map-matching would make the database sluggish and slow to update itself. And when there is a large disparity between the state of the roads in the real world and the in the database it becomes a problem, especially if it takes a long time before it is updated.

A different note to consider is the possibility to limit the amount of segments in a GET-request to counter the amount of data that is loaded in one request. It is not desirable to load the segments of a road in Oslo when the user is looking over Trondheim. A possible solution to this is to only request the segments that are within a given radius of the users “view” in the frontend.

If the API is to be scaled up to be nationwide we would strongly recommend that the performance of VAPI is improved upon first. But it is ready to cover the whole country if users of this API is comfortable with the current performance.