Overview

The first thing to do is to clarify the key data of the project. For this we use the W-questions:

• What benefit should the webapp have?

• Who is the webapp aimed at?

• Why do I want to develop this webapp?

• When should the first version be ready?

• How much budget is available for the development?

• From whom (competitors) do I want to differentiate myself?

With all W-questions, negation is also particularly interesting, for example: Who should the web app not be aimed at, which user group can we deliberately ignore?

Creating the requirements documentation

Identification of core functions for the MVP

Once the requirements have been captured, the core functions for the MVP need to be identified. The MVP, the Minimum Viable Product, is the basic version of the software that contains all the essential functions and features that are absolutely necessary to solve the users' problem.

When it's difficult to draw the line ...

Then it helps to divide the features you want into 4 categories:

• Must have

• Should have

• Could have

• Won't have

This type of subdivision is called MoSCoW prioritisation. In the best case, the MVP consists only of the must-haves and dispenses with the should's and could's as far as possible.

Identification of functions for subsequent versions

Once the core functions for the MVP have been identified, the functions for subsequent versions need to be identified. These functions can be added gradually to improve the software solution and meet further user needs.

Creation of requirements documents and user stories, starting with the MVP

To ensure that the software meets the needs of the users, requirements documents and user stories must be created. These documents describe how the software should work and what users can expect from it. This starts with the core functions of the MVP and later expands to the functions for subsequent versions.

What are user stories?

A user story is a short, concise description of a function from the user's perspective (role, scenario). It describes what the user wants to do and why. User stories are used in agile software development to gather requirements and inform the development team about how the app should behave.

Examples of user stories:

• As a user, I want to be able to log in with my username and password to access my account information.

• As an administrator, I want to be able to send notifications to users to share important information.

Development of the MVP

Once the requirements documentation and user stories have been created, the development of the MVP can begin. Here, the core functions are implemented to create the basic version of the software solution.

First user tests with the MVP

After the MVP has been developed, initial user tests should be carried out to check whether the software meets the users' needs. Feedback is collected here to improve the planning based on user needs.

Why it is important to test early with real users

It is important to test early with real users as this helps to gather feedback and ensure that the software meets the needs of the users. Early testing allows problems to be identified and fixed before the software is released.

How planning is changing based on user feedback

Planning based on user feedback is changing as feedback is used to improve the software. User feedback helps to identify weaknesses and opportunities for improvement and to make changes to meet user needs.