Requirements, Design and Team
This project's goal is to build an extensible prototype of a full-stack web application for gamers to manage heterogeneous game collections easily. This application will also allow an user to find other gamers to play with, and will allow her to join gaming clubs in a geographical area.
After starting with an initial set of requirements from the brief, we prioritized the list further following some additional context from a discussion with the Product Owner (PO) via email. We deduced further insights from answers to a list of questions that were sent over to the PO, and we updated the list to focus on a core set of features.
We believe that the focus should be on simplicity. We aim to build a simple application that focuses on solving the main customer pain points. We do not aim to offer too many features. Having too many features will make the application cumbersome, and will increase the risk of project failure. Some competitors that we have studied (e.g. BoardGameGeek) offer too many features, which makes the user experience (UX) confusing. We believe that focusing on a core set of features will make the UX enjoyable for our target audience of gamers.
2.1 MoSCoW method
We have used the MoSCoW method to help us prioritize our requirements. The MoSCoW method allows teams to prioritize product requirements into different priority buckets of 'Must have', 'Should have, 'Could have', and 'Won't have (this time)' [1].
All the requirements below are denoted at the end with a combination of single or multiple letters inside brackets that signify where the requirement came from. Below are the keys of these attributions and their definitions. For instance, if a requirement is denoted with [B,C] at the end, it means that the requirement is attributed to both the product brief and research on competitors.
Key:
[B] Requirement is attributed to the product brief.
[P] Requirement is attributed to discussion with Product Owner.
[C] Requirement is attributed to research on competitors.
2.1.1 Must have
Functional:
• Allow user to search for games [B,P,C]
• Allow user to add games [B]
• Allow user to update games [B]
• Allow user to delete games [B]
Non-functional:
• A web application with a set of simple features to manage game collection across types (e.g. board, card, miniatures) [B,C]
2.1.2 Should have
Functional:
• Allow user to search for games she does not have [B,P]
• Allow user to read reviews of games from user community [B,P]
• Allow user to read reviews of games from websites (e.g. board, rpg and card game review blogs, and published online magazines) [B,P]
• Allow user to add her own review [B]
• Allow user to rate games [B]
• Allow user to see average ratings of games [B]
• Allow user to share house rules and clarifications for games [B,P]
• Allow user to embed FAQs and errata documents from publishers [B]
• Allow user to see recommendations of new games based on her reviews, collection, and popular games in her geographical area [B,P]
• Allow user to search for new players to play with based on custom specification (e.g. collection, interest) [B,P]
• Allow user to search for clubs in a custom geographical area [B,P]
• Allow user to view average price of a new or a used game from different sources (e.g. Amazon, Geek Market) [B]
• Allow user to go to game seller's website from the game record [B]
Non-functional:
• A web application with an intuitive user interface (UI) to search for games, read reviews, add reviews, see ratings, add ratings, share house rules, view game recommendations, search for new players, search for clubs, view prices, and visit seller’s website [B,P,C]
2.1.3 Could have
Functional:
• Allow user to rate games publicly or privately [B,P]
• Allow user to view games in her collection based on specific criteria or categories (e.g. number of players, game type) [B,P,C]
• Allow user to search for games based on specific criteria (e.g. number of players, game type) [B,P,C]
• Create a system to accept or ignore game reviews based on a selection criteria [B,P]
• Create a weighting system to compute ratings [B]
Non-functional:
• Artificial Intelligence (AI) driven model to filter reviews automatically [B,P]
• Statistical model to compute weighted average ratings [B]
2.1.4 Won’t have (this time)
Functional:
• Allow user to play games in-app [C]
• Allow user to chat real-time with other users [P,C]
• Allow user to create a game wish list apart from her own game collection, which are the games she has played [P,C]
Non-functional:
• Mobile application (e.g., iOS or Android) [C]
2.2 Capture Methodology
We discuss our requirements capture methodology below.
2.2.1 Read brief
We read the brief thoroughly and listed an initial set of requirements.
2.2.2 Discussed questions from brief with PO via email
We sent over a list of questions to the PO to receive clarifications on a few areas from the brief and on the overall project. The additional context from the PO enabled us to prioritize the requirements list further.
2.2.3 Researched competitors to discover customer pain points
We researched some competitors offering similar features to our requirements (e.g. BoardGameGeek, GameFAQs, GameZone, Pogo, Polygon, AreYouGame.com, BoardGameCo). The research helped us to understand the main customer pain points (e.g. too many features, confusing UX, information overload, inconsistent theme of webpages). This understanding enabled us to prioritize the requirements list further, and provided more confidence in our set of requirements.
Our target is to build a prototype showing a high degree of flexibility and extensibility for future development. We are thinking about using third-party libraries as much as we can to make development easier, and in consideration of easier maintenance in the future. Many widely used libraries (e.g. numpy) are optimized for speed, which will return good application performance and will keep us away from reinventing the wheel with many components. Also, cloud services may be helpful to use as they have a good selection of algorithms, they are quite straightforward to apply, and they support multiple programming languages.
Overall, we predict that there will be some learning involved as our current skill level may not be sufficient to create an excellent full-stack web application. However, we we do need to be careful as too much learning will take too much time and will leave us with little time to finish the project. So, we think a good strategy would be to rely on what we are comfortable with best, and add incremental skills on top of it to develop the core features and create an attractive UI for our users. In this way, we can strike a balance between our learning curve and functionality of the product.
We will leverage test-driven development (TDD). In this way, we can catch bugs early and only implement enough code to pass the predetermined tests. This will let us prioritize what needs to be implemented, and not waste time on additional functionality. We will have a code review process when each team member has completed his implementation.
3.1 Technology stack
Below is the current aggregate of the technology stack of our team at varying levels of skills. We will select the technology stack for the application from our available pool of skills, and add any incremental skills as required to build our application.
Frontend: HTML, CSS, JavaScript, React
Backend: Python/Flask/Django, Go, Java/Spring
Data Management and Analytics: PostgreSQL/MySQL, MongoDB, Anaconda (numpy/pandas/scikit-learn), TensorFlow, Spark
Test: PyTest/unittest/PyUnit, Go standard library, JUnit
Version Control: Git/GitLab
Development Environment: Command line, Jupyter Notebook, Visual Studio Code, Eclipse
3.2 Architecture
We have decided to develop the application with a layered architecture pattern due to its simplicity, ease of development, and high testability [13]. The layered architecture is suitable for applications that are needed to be built quickly, which is a relevant feature for this project due to its prototyping nature with a small team. The high testability of the pattern such as the ability to mock the presentation component to isolate testing will allow us to build an application that is highly functional.
As with all architecture patterns, layered architecture pattern has its downsides. It has low agility, low ease of deployment, low performance, and low scalability [13]. It can be difficult to make changes. A minor change requires redeployment of the entire application. The pattern is not convenient to create highly performant applications. Lastly, this pattern is difficult to scale. However, we believe that these issues do not affect our project.
We will build our application with a modular design. The modularity of the application addresses the agility problem of layered architecture by enabling efficient incremental upgrades [14]. As our application is small in nature, redeployment of the entire application after a minor change will not be a major bottleneck. The low performance of layered architecture is not relevant to our project as a highly performant application is not one of our requirements. Lastly, we are not concerned with scalability yet as we are building a prototype. These are the reasons for which we consider applying a layered architecture, despite of its shortcomings.
Some alternative software architecture patterns that we have studied are event-driven, microkernel, microservices, spaced-based, client-server, master-slave, and pipe-filter [13]. A suitable pattern that we considered was microservices due to the pattern addressing some of the issues of layered architecture (e.g. agility, ease of deployment, scalability). However, none of the developers in our team are experienced with the pattern. As we want to minimize risk of project failure, we decided not to apply the pattern this time.
We are aiming to create a REST API (Figure 1) at the backend (with Flask, Django, or Spring based on skill level) to allow CRUD (Create, Read, Update, and Delete) operations with a database of choice (e.g. PostgreSQL). The response from the API could be in JSON as it is widely used with modern applications. We think that a monolithic architecture (as opposed to microservices) would be relevant as we are aiming for a simple prototype rather than a complex production-quality cloud application. The prototype will enable evaluation for further development and extensibility.
At the frontend, we aim to use HTML, CSS, and JavaScript to create dynamic webpages. We may use a frontend framework (e.g. React) and other tools (e.g. Bootstrap) if these help us to develop efficiently and to create an attractive UI.
For machine learning (ML), we aim to apply highly supported technologies (e.g. TensorFlow, Keras, Spark, scikit-learn) based on skill level and other practicalities. We think that the main use case of ML in this project is to recommend games to our users based on their reviews, collections and communities. Building a recommendation engine using scikit-learn or another ML framework would be suitable for our product. We do not think Natural Language Processing (NLP) models are necessary to be deployed due to their over-complexity and our limited time of development.
For development environment, we prefer to use VS Code or Eclipse for web development and Jupyter Notebook for prototyping machine learning models.
Figure 1: REST API model [3]
We will adopt a Model-view-controller (MVC) software design pattern (Figure 2) [4]. Many web frameworks such as Django and Spring facilitate implementation of the pattern.
Figure 2: MVC Architecture Pattern [4]
We used Lucidchart [11] to create an initial system design of the web application, applying the concepts that we have discussed above (Figure 3). We will iterate on this design as needed to optimize our application.
Figure 3: Current software architecture of game management web application
3.3 Design
We prefer to use object-oriented design for our application, which is documented as an UML diagram below (Figure 4).
Figure 4: UML Class Diagram
There are several objects with specific attributes to accommodate the requirements:
- Object "Game" has several attributes, i.e. no_of_player, est_playtime, game_type, which can be used as searching criteria and data for recommendation engine.
- Object "Forum" is created for allowing users to interact with other users by asking questions and sharing errata documents.
- Object "Price" and "Rating" are created and used to calculate average price and rating of a game.
- Review of a game is split into user and public type to address the requirement.
- Object "Club" has the attribute of gps_location to allow the user to specify certain location to search for clubs.
- Various child objects such as "Card Game" and "RPG Game" could inherit "Game" with more attributes and methods added for handling the specific type of game. For example, card game collection usually have multiple cards coming from different booster packs. Object "Card Game" should have extra methods to handle such characteristic.
We will create pseudo-code and prototype of the application using the UML diagram as our foundation.
3.4 Implementation Paths
We think that the following implementation path would be ideal for our application. The details of the implementation will be more clear during the second phase of our project.
- Database Schema Design
The database will have tables designed to store user data, collection and game data efficiently. Moreover, extra tables to store game prices, ratings, reviews and clubs will be created and joined with other tables if necessary. Below is the entity relationship diagram (ERD) of our database (Figure 5).
Figure 5: Entity Relationship Diagram
-
Database Stored Procedure Design
Stored Procedures are created to serve as the main logic of how data goes in and out of the database. For example, when a user adds a game to her collection, the collection table should have one record inserted with corresponding user ID and game ID. -
Backend (REST API) programming
This part aims at creating the unified interface (for GET, POST, PUT and DELETE operations) and how it links to the database's stored procedures. For example, when a user wants to see a list of games of a certain category (e.g. RPG), the interface should perform a GET action, and a stored procedure in the database will be called, which will return the required data. -
Frontend design
The Frontend will be designed based on the UI prototype described in Section 5 below. Moreover, we will design how elements in the page interact with the server via API. For example, when a user clicks on a game image on the index page, the application should perform a GET action on relevant game information, which are displayed in the game's profile page. -
Machine Learning system design
The design of ML system is to recommend games based on the user's collection and interest. This can be done separately so it's arranged in later stage of the development. A module (preferably in Python) will be constructed in the server-side to extract database's information of a user and to return a list of recommended game IDs. -
ML Integration into Backend
We aim to integrate the ML module into the REST API, in which the script should be called via GET action and returned with a list of game IDs. -
Frontend refactoring with regard to ML
Based on the returned game IDs from the ML algorithm, the API will extract the information of the games. We need to modify the frontend UI for displaying the recommended games to the user. -
Final tuning and testing
Throughout the implementation of the steps, unit testing will be deployed for each module to ensure the functionality of each part. An integration testing will be carried out, and we will fine-tune the web application at the last stage.
In this section, we discuss the Flow and UI Prototype of our application.
4.1 Interaction, Data, and Control Flow
As PO discussed during our team discussion, the key at the start of the UI design is to get the flow in place, which are interaction, data and control flows [18]. Based on the software architecture that we have discussed above, we created a sitemap (Figure 6) using Figma [16][17] to show the flow of our application. The sitemap visualizes how the features of our application and its associated pages will flow in the user journey. We will iterate on this sitemap as needed to improve the design of our application.
Figure 6: Current sitemap of web application
4.2 UI Prototype
For UI Prototyping, we are also using Figma to create wireframes and high fidelity mockups of our application [7]. Our design considers accessibility for different users. Our focus on designing the UI is on simplicity. We believe that simplicity will result in an intuitive and enjoyable UX for our target audience.
Below are some sample wireframes of our UI. We will iterate on these wireframes as we see fit for our end users as we move through the course of the project. Figure 7 displays the current iteration of our home page.
Figure 7: Current wireframe of home page
Figure 8 displays how a typical search engine would look like in our application, using the game search page as an example. We will use a consistent design for the search engines of players and clubs.
Figure 8: Current wireframe of game search
Figure 9 details how information about a particular game will be displayed when a user clicks on a game from the search engine or from the recommendation engine. The game profile will display basic metadata of the game, ratings and reviews, forum for gamers to exchange information, and prices from vendors.
Figure 9: Current wireframe of game profile
Figure 10 details how user profile will be displayed. The profile page will display the user's basic details, her collection, and some recommended games.
Figure 10: Current wireframe of user profile
In this section, we discuss team structure and role assignment of our software project.
5.1 Members
Here are the development team members below in our project:
(1) Sujan Hyoju
(2) Tom Chan
(3) Nabil Shadman
As one of our developers has been inactive since the beginning of this project, we assume that this will be the case throughout the rest of the project. This will enable us to plan ahead better and manage risk. For instance, we may reprioritize components that we will implement as we may not be able to complete all of the requirements on time with a reduced team. These details will be clear in the second phase of the project when we estimate time to implement the components of our system.
5.2 Work
The development work can be broadly divided into the four parts below:
(1) Frontend (UI/Views): Work for this part will be distributed between Tom and Nabil
(2) Backend (Server/Database): Nabil will take the lead on this part
(3) AI (Data/ML Engineering): Tom will take the lead on this part
(4) Testing (Automated/Regression/Unit): Application will be tested by Tom and Nabil for their respective parts
For the assignment of work, as Testing is more general, each member will write own testing scripts for their respective parts. As Tom is relatively more familiar with AI, he will own the AI part. As Nabil is relatively more familiar with Backend, he will own the Backend part. As both members are not much experienced with Frontend, we will leverage a divide-and-conquer strategy to split the work on the Frontend.
In this distributed work strategy, we establish accountability for our own parts. Any load imbalance could be adjusted by assisting each other out. So, for example, if Tom has too much work on the AI side, Nabil can be pulled in to implement some components on the AI side. In this way, both members have accountability and load balance. We will get a clear idea on how to distribute the work precisely when we estimate time to implement components in the second phase of the project.
5.3 Communication Process
Our communication process has been mainly via the methods below:
(1) Asynchronous Communication with group members via Microsoft Teams
(2) Option to set up live virtual meeting if better to discuss certain items
(3) Issues feature in GitLab to assign specific tasks to team members
(4) Email communication with Product Owner
[1] https://en.wikipedia.org/wiki/MoSCoW_method
[2] https://sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/requirement_sources.html
[3] https://blog.iron.io/what-is-rest-api/
[4] https://www.freecodecamp.org/news/the-model-view-controller-pattern-mvc-architecture-and-frameworks-explained/
[5] https://www.monocubed.com/best-front-end-frameworks/
[6] https://www.datacamp.com/community/tutorials/recommender-systems-python
[7] https://www.youtube.com/watch?v=c9Wg6Cb_YlU
[8] https://faq.postgresql.tw/postgresql-vs-mysql
[9] https://engineering.linkedin.com/blog/2015/12/test-stability---how-we-make-ui-tests-stable
[10] https://en.wikipedia.org/wiki/Class_diagram
[11] https://www.lucidchart.com/pages/
[12] https://www.youtube.com/watch?v=wYk0xPP_P_8
[13] https://www.simform.com/blog/software-architecture-patterns/
[14] https://www.jigsawacademy.com/blogs/product-management/modular-design/
[15] https://www.youtube.com/watch?v=pwHtcKmwPDA
[16] https://www.youtube.com/watch?v=W8smyf1eHFk
[17] https://www.figma.com/
[18] https://git.ecdf.ed.ac.uk/sd2122online/group_2/-/wikis/Notes