Summary of the Methodology

Each phase of the SDLC that is used in the further course of this work is explained in detail. Each phase describes the process of how the goals defined in Section 1.2 can be achieved. The SDLC consists of analysis, design/concept, implementation, and testing/feedback. Each of these stages includes reflection meetings with the entire team because each member is involved in the whole development process.

4 Results

This section presents the results that could be achieved by implementing the phases described in Section 3. Therefore, the section is divided into the analysis, the concept, and the implementation phase. Furthermore, a requirement comparison follows after the implementation to emphasize if the requirements are fulfilled.

4.1 Analysis

”Software development can be defined as the process of designing, programming, specifying, documenting, testing, conceptualizing and debugging that go together in the development and maintenance of various Frameworks, applications and other components of the software help.” (IntroBooks Team,2020)

In the first step of a software development process, it is necessary to figure out what potential users expect from the application in order to be able to specify and design the application. Besides, the user’s needs have to be analyzed, structured, and adjusted by the whole project team to ensure that the needs are technically feasible, that they have been understood, and will be met.

Therefore, the following section deals with RE and the subsequent pri-oritization of the resulting user needs. The requirements themselves are structured into functional and non-functional ones. The desired state can be established from these requirements. With the help of sketches of the system architecture, the actual state will be demonstrated.

32

4.1.1 Requirement Engineering (RE)

RE, explained in more detail in Section 2.2, is the process of generating requirements. Gathering potential users’ requirements for the application is an essential and mandatory step at the beginning of the development process. In our case, the needs could be determined by analyzing existing similar platforms and working closely with soccer fans and soccer clubs, which will be mentioned in the actual analysis part below. As a result, all the resulting software requirements are explained and divided into functional and non-functional requirements below, as recommended by Sommerville and Sawyer,1997.

Actual State

In the process of capturing, analyzing, and specifying the requirements for a software product, it is essential to examine the domain of the application.

In the first step, the relevant actors are determined. In the case of this work, the relevant actors are fans of certain soccer clubs who are represented on this platform or simply soccer enthusiasts in general and the soccer clubs of course.

The soccer teams are also actors since they use this platform to distribute their content. The news articles are part of this content. This platform has a separate web page for creating the news articles, which get distributed on the native apps and the web application that gets developed in the further course of this work.

After the actors have been determined, it is also important to mention which mediums are available in order to be able to gather and integrate requirements, especially user requirements. First and foremost, the native applications already mentioned in Section 1, which are still being revised, are used as a prototype. Therefore, there are already some users who inform the platform about missing features or features that need improvement.

Thus, the wishes of those interested in soccer are caught up and taken to heart, which is absolutely crucial for the success of a product. Because it is an interdisciplinary collaboration between the developers, the product owner, and the colleagues from sales, there is still another medium through

Figure4.1: The figure sketches the system architecture of the actual state.

which feedback is obtained. That feedback comes from the soccer clubs themselves and is obtained through the colleagues who work in sales. They maintain contact with the soccer clubs by showing them the product and convincing them to become part of this soccer platform.

Another method in determining requirements is the observation and anal-ysis of similar platforms already available on the market. Therefore, state-of-the-art observations are an essential part of gathering additional user requirements. Nevertheless, there is still another method for gathering needs, namely, involving requirements that had already been implemented in the apps and were well received by the end-users. These needs will be transferred to the web application. The requirements are adjusted and checked in consultation with the entire team on-site in discussions or via a business communication platform. These discussions ensure that objections, suggestions for improvement, or problems can be addressed. Therefore, regular reflection meetings are the most crucial part of developing this whole product.

System Architecture Overview of the Actual State

Figure 4.1 illustrates the architecture of the current situation. As already mentioned in Section 1, the content of the soccer platform is currently only available in the native apps for Android and iOS. Nevertheless, the native apps are still being developed and cannot be considered complete.

Since the soccer platform is still in its infancy, there are currently many changes in terms of requirements and design. However, these apps at the current state can be viewed as a prototype to obtain users’ opinions. The

users share their suggestions for improvement to the support team and the product owner via email. Thus, the wishes of the users can flow directly into the development. Furthermore, the colleagues who work in sales use these apps as a prototype for convincing the soccer teams to be part of this platform, as mentioned before. They must must be able to demonstrate already existing functions when they want to win the teams over for this platform by convincing them about this platform’s value. Furthermore, a few teams are already part of it. Thus, their feedback and wishes can also flow directly into the development process.