Let's build a website
This is the first article of many of building a fully functioning web site, using Java, Spring Boot, and JavaScript. We'll create a website to list existing and upcoming video games with a modern UI.
The website
The website we will be building during the course of these articles, will give a modern UI for the user to browse existing and upcoming video games. The UI should be visually pleasing and responsive, because all gamers are accustomed to having that kind of experiences in their games as well. The purpose of the website is to be able to view screenshots and videos of the games, read their descriptions, see when the games have been released (or when an upcoming game is supposed to be released). It will have powerful search capabilities, so the user can quickly find what they are looking for.
The data
IGN offers a free API for us to use, to retrieve information about existing and upcoming video games. The API documentation can be found here. They provide meta data, such as the names, and descriptions of the games, but they also provide images and videos, that we’ll be showing on our website, when you view a game.
Requirements
In professional environment there are different kind of software projects:
Customer ordered, tailored projects
In-house developed software products
R&D projects
Internal tools
Etc…
When a customer orders a project from us, they usually provide requirements for the project. Our job as software developers is to understand the actual meaning behind the requirements, so we can build the software the customer wants. This usually involves having some kind of refinement talks with the customer after we’ve had time to familiarize ourselves with the requirements. It is also very possible that the requirements are written in co-operation between the customer and the developer.
When we have an in-house product, we don’t have a specific customer yet. Or we could have multiple potential customers, such as video game enthusiasts around the world. No one is there to give us the requirement documentation. So we can build what ever we want, right? Of course we can, but is it a good idea not to have any guidelines for our product? Maybe not. So we should write our own requirements for the product. This gives us a good understanding what we are going to build, and to prevent scope creep from making our product an everlasting project.
Each requirement should have an identifier, so we can refer to them by it in any tools or documentation, or talks. Usually requirements are originally documented in an Excel sheet, and once the requirement documentation as a whole is accepted, they can be entered to a tasking software such a Jira.
We’ll list our requirements in a numbered bullet list, because of the format of this newsletter / blog.
Game browser requirements
Here are the requirements for project “Game browser”:
The user interface shall be a website.
The website shall list existing video games.
The website shall list upcoming video games.
The games shall be searchable by name, description, year of release, rating, favourite status, and genre.
Where available, images and videos shall be viewable for each video game.
A rating of the game shall be displayed.
It should be possible to favourite a game.
There, a list of requirements for version 1. Not a lot of requirements yet. We can create a new list of requirements, once we have finished version 1.
Let’s familiarize ourselves with the requirements
Now is the time to read the requirements and really understand what they require from us. First, note the wording in each requirement: shall and should. A “shall” requirement is an absolute must to be implemented. A “should” requirement is optional. That is, we will implement “should” requirements if we have time. If this were a customer ordered project, we could offer features based on “should” requirements in an option, with their own price tag. So we would be basically saying: “If you pay us a little extra, you also get this and that”.
Another thing to note is that, none of the mandatory requirements require us to store any user data. If we implement only mandatory requirements, we only have read-only data. Think of that for a second. The optional requirement number 7 doesn’t sound too difficult to implement at first. But it is the only requirement that would make us implement user data saving functionality. That is a whole new system compared to all the other required features. Again, if this were a customer ordered project, the option for the “favourite” system should include the price for building all that user data storing system as well, not just one button on the UI. This should also be communicated to the customer, so they understand why the price might be a bit higher than initially thought.
Features
Now that we have finalized the requirements, we either could just start with building the software, or we could write detailed descriptions of the features we build. The features should be based on the requirements. They don’t need to be one to one mapped to the requirements, but they can be. It is up to you basically.
Development process
In professional software development there exists many kind of software development processes. The word “Agile” is often included in these process somehow. Possibly the most used process today is Scrum. Someone even has said that Scrum is a cancer (not me). Anyway, I won’t be covering scrum or any other process or project management model. This article series is about the technical side from now on.
In the upcoming articles of this series we will build the software in question. Next time we setup our backend and frontend projects, and get something visible on our website. Until then, keep coding!
Ps. The most difficult task is this one: What should we call our project? Write your suggestions in the comments.
🔥Nice! Can't wait for part2