When developing a new application, the requirements analysis is one of the most important parts. A proper analysis saves a lot of time in the development phase, and reduces the need for rework and stress on all parts, from Developers to Customers.

In this particular area, low-code applications are no different than applications developed in a traditional way. Since we’re always looking for ways to simplify the development of applications in our low-code platform, we asked ourselves the following questions:

• Using a no-code approach, can we give our developers a way of writing application requirements that eases the mapping to the platform concepts?
• Can we go a step further and generate automatically an application based on the requirements?
• At last, can we automate tests to our generated application?

With these requirements in our minds, and with the support and knowledge of investigation teams in ISEP and FEUP universities, we’re happy to finally say that a solution has been found. Let’s take a look at it, step by step.

Step 1: Define the requirements

Starting with the definition of the requirements, our proposal takes advantage of the languages ecosystem described here to provide a controlled environment where citizen developers can write the application requirements in a natural language. The tool selected for this job is Jupyter Notebook.

Jupyter Notebook allows modelers to write the requirements in an easy-to-use text editor, having the advantage of allowing the process of the written text and translating it to other formats.

In the image above we can see an example of the requirements for a Purchase Order application. Always using natural language, the modeler can identify the entities, their attributes and state machines. He can also describe the business rules to be later written by a programmer using C#.

To help with the creation of the structure seen above, a set of snippets will be available to automatically generate the tables, add an attribute, state machine, and all the other time-consuming operations.

As we can see, the modeler is invited to write in a readable format. He can even use this resource later as project documentation.

Step 2: Automatically generate a model

Now that we have our model described, the next step is to have it synced to an OMNIA tenant. To do this, we’re using Visual Studio Code along with an extension made specifically to work with the platform.

This extension uses the result of the processed Jupyter Notebook file and automatically validates and syncs it with the desired tenant.

Step 3: Test your model

At last, after the model is developed, it’s time to test. To keep the test development available for any modeler, the tests are also written using natural language, using Jupyter Notebook.

The tests are defined by a set of steps to be executed automatically on a web browser, simulating the user interaction with the application.

Since we’re using the patterns and tools adopted by the Behaviour Driven Development community, the tests are written on the domain-specific language Gherkin. Let’s see an example: