Breaking out the requirements — Final Year Project Blog
In the previous post in this series, I introduced the project that I will be working on for my Final Year Project to earn my degree in BSc Computer Science.
I discussed the overall structure of the project and how the system is intended to work. It’s digital picture frames, but a complete remote management system to control it. This essentially means that the content displayed on the Digital Picture Frame, henceforth referred to as “Frame”, will be managed from an app that does not live on the Frame itself.
The Frame will contain an app which will display the content and allow the user to interact with the Frame directly, however, the main app to manage the system will be available as an app to be installed on a mobile device, allowing the user quick access to display new images on the Frame.
But how exactly will I achieve this?
As was discussed previously, the system will be made up of various subsystems. They are:
- The Frame Management System — Allows the user to manage the content shown on specific Frames
- The Gallery Management System — Allows the user to upload images to the cloud storage and create Slideshows of images
- The User Management System — Allows a user to register an account which will be used to access and manage their Gallery and Frames
- The Device Registration System — Allows each Frame to be assigned to a user to prevent unauthorized control of the Frame
To create these subsystems, I need to evaluate precisely what end-products need to be produced for each of these subsystems to achieve their goal.
I’ll take each of the subsystems in turn and discuss in more detail what each should do and how the user should interact with the subsystem to determine clear end-products that need to be developed.
The Frame Management System
The Frame Management System, henceforth known as Cumulus, has the following set of aims:
- Display content on the Frame
- Change the content shown on the Frame
The aims for Cumulus are very simplistic, however, when fit into the overall system, the complexity tied to achieving these aims increases.
To display content on the Frame, we need to answer a few questions. I have listed the questions that I asked myself and my answers to them below.
How will we display the content?
The content will be displayed full screen on the Frame via an app installed on the Raspberry Pi. This app should be the default launch program of the Raspberry Pi and should not allow an average user to close it easily.
Where does the content come from?
The content will be retrieved from a cloud store associated with the user account linked to the Frame.
How do we know which content to display?
The app on the Frame will do a lookup against a cloud database to retrieve the settings for the Frame. Within these settings, it will dictate which content to display.
What happens if the Frame cannot connect to the internet?
The app should download a local copy of the content when connected if the local copy does not already exist. Once a local copy exists, the app should use this copy in preference over the hosted copy. If the hosted copy is deleted, it should also remove the local copy.
In regards changing the content displayed on the Frame, the user has two primary methods of changing the content shown on the Frame.
The first is through the use of the companion mobile app, wherein they will have the ability to select a Frame, then select the content to display on the Frame. The options available for the content to display will come from the Gallery associated with the user account.
The second is by directly interacting with the Frame itself. The Frame should provide controls for the user to interact with the Frame to change the content being displayed. It will show the content saved locally first, then display any other hosted content that has not yet been stored locally on the Frame. It will not store any additional content locally unless it has been selected to help prevent storage from being used. To minimize the impact of the content being stored locally on the overall storage of the Raspberry Pi, it may be worth implementing a strategy of only storing the previous X amount of set content on the Frame.
The Gallery Management System
The Gallery Management system, known as Cirrus, will aim to achieve the following:
- Allow the user to upload images
- Store uploaded images in a cloud store
- Allow the user to create Slideshows from uploaded images
For Cirrus to accomplish these tasks we need to look at what each of these goals involves.
To allow the user to upload images, we need to think about where the user will upload the images from, and where they are uploading the images to.
As most people use their mobile devices to capture special moments in their lives, it makes the most sense to place an app directly on the user’s mobile device that can access the internal gallery of the device. The image then needs to get sent to a backend service of some form which will then process the image and pass it on to the next step.
The next step in the process will achieve the aim “Store uploaded images in a cloud store”. The backend service, once the image is processed, must then store the image in a cloud-based store that can only be accessed by the user that uploaded the image.
Finally, to allow the user to create Slideshows from their uploaded images, Cirrus must allow for the user to create an entry in a database that links together multiple uploaded images to a single Slideshow definition.
The User Management System
The User Management System, known as Stratus, will be a basic user authentication system, used to restrict the access to Cumulus and Cirrus on a per-user basis.
Ideally, Stratus should allow the user to use social login when setting up their account, preventing the need for them to create an account to be managed by the system itself. However, not all users may have an account with one of the providers or they may prefer not to tie their accounts to the system, and therefore a simple self-managed authentication system must be provided to allow for this.
Stratus should only store necessary information about the user such as:
- Email Address — For logging with accounts and for password recovery if the user sets up an account with Stratus Self-managed Auth
- Hashed Password — For password verification
- Name — For personalised greetings and communications.
- Social Provider ID — For social login
The self-managed system should allow for password recovery as well as password change and potentially email change.
The Device Registration System
The Device Registration System, known as Nimbo, will be a basic system used to link the Frame to a User. The Frame will have an app installed on it which on the first run, will force the user to tie an account to the Frame to allow the user to manage the Frame via Cumulus.
When the app is first run, it will generate a unique ID for the Frame which will be assigned to the user.
Conclusion
After examining each of the subsystems, in turn, we can see that some key deliverables need to be produced:
- An IoT App to be installed on the Frame
- A Mobile App
- A Cloud-based Backend Service
- A Cloud-based Store
- A Cloud-based Database
The discussions on each of the subsystems above highlight at a high-level the requirements that the system must fulfil, and a requirements document can be generated from it. The requirements document will then be used when developing the system to ensure each system is built correctly to achieve their respective aims.
The next step
Next to complete will be the research into the possible technologies that can be used to develop each of the subsystems within the overall project. I’ll go into detail about the technologies that are available, their pros and cons, which I’ll be using and my decision behind choosing that particular technology.
