MARPa: A Software Modelling Assistance and Requirements Pattern-based Method for Low Code No Code Software Development - Technical report, focus group demographics, perceptions, and quotes

MARPa: A Software Modelling Assistance and Requirements Pattern-based Method for Low Code No Code Software Development – Technical Report David Mosquera1[0000-0002-0552-7878], Jolita Ralyté2[0000-0001-8561-3567], Marcela Ruiz1[0000-0002-0592-1779], and Oscar Pastor3[0000-0002-1320-8471] 1 Zürich University of Applied Sciences, Gertrudstrasse 15, Winterthur 8400, Switzerland {mosq, ruiz}@zhaw.ch 2 University of Geneva, CUI, Ballette Bât. A, Route de Drize 7, 1227 Carouge, Switzerland [email protected] 3 PROS-VRAIN: Valencian Research Institute for Artificial Intelligence - Universitat Politècnica de València, València, Spain [email protected] 1 Introduction What elements—a.k.a., method chunks—compose a method to benefit from requirements patterns and modelling assistance in LCNC approaches? In this technical report, we include a detailed description of method chunks composing MARPa: a Software Modelling Assistance and Requirements Pattern-based Method for Low Code No Code Software Development. This technical report compiles the method chunks, process map, and metamodel from MARPa. This technical report is a complementary material from a method-oriented paper currently under review at SoSyM Journal. 2 A Catalogue of Chunks for MARPa Based on the SME [1], a method chunk implements a strategy to achieve an intention. Intentions represent the objective or desired outcome that a method chunk is designed to fulfil. To answer RQ1, we follow an exploration strategy to identify method chunks [1, 2], identifying chunks by analyzing intentions. This implies that we identify method chunks by considering different ways/strategies to achieve the desired outcome from a specific intention. We analyze four intentions for identifying method chunks: i) select a requirements pattern template, ii) populate a requirements pattern template, iii) create software models, and iv) refine software models. Moreover, as mentioned in RQ2, we aim to provide MARPa with a set of context criteria. In SMEs, context criteria have already been categorized and framed into reusable frames [3, 4]. In MARPa, we consider context criteria related to user involvement, project size, tool availability, and available resources—in terms of effort and human expertise. 2 Mosquera et al. 2025 2.1 Chunks for Selecting Requirements Pattern Templates The MARPa process starts by selecting a requirements pattern template. With this intention, requirements engineers aim to find the requirements pattern template that better fits the software requirement under development. In requirements pattern methods, this intention is referred to as pattern/form/part exploration [5] or selecting a template based on domain and scope [6]. As input, this intention expects there to be a catalogue where requirements pattern templates are stored. Then, requirements engineers can use different strategies to select a requirements pattern template from the catalogue. After analysis, we identify strategies to achieve this intention, such as using classification schemas (C01), based on similarity (C02), or interacting manually with the catalogue (C03). We consider that selecting one of these strategies will depend on the catalogue's size (XT01), the expertise of the requirements engineers (XT02), and the availability of tools (XT03). We summarize the chunks we have identified for selecting requirements pattern templates in the following tables. Table 1. Method chunk C01: Selecting a requirements pattern template by using a classification schema. ID C01 Goal Requirements engineers filter the catalogue based on features [15], domains [16], and non-functional requirements [11], among other classification schemas, to select a requirements pattern template. Input 1) Classification schema 2) Available requirements pattern templates as a catalogue Activity Using a classification schema filter the requirements pattern catalogue. Then select a requirements pattern template from the filtered catalogue that fits and addresses the needs of an undergoing software development effort. Output Selected requirements pattern template Roles Requirements Engineer Criteria XT01 - Catalogue size: Medium-sized catalogue XT02 – Expertise of requirements engineer: Mid-level expertise XT03 – Availability of tools (classification schema): Available The MARPa Method 3 Table 2. Method chunk C02: Selecting a requirements pattern template based on similarity. ID C02 Goal Requirements engineers use the similarity calculation [24] between requirements pat-tern templates and other requirements engineering artefacts—e.g., requirements documents and textual descriptions—to select a requirements pattern template. Input 1) Artefacts for calculating similarity. 2) Available requirements pattern templates as a catalogue Activity Input both artefacts and requirements pattern template catalogue into a similarity calculation tool. Calculate the similarity between the artefacts and the available requirements pattern catalogue using template’s goal, description, and title, among other template elements. Order by max to min similarity to filter the requirements pattern catalogue. Select a requirements pattern template from the filtered catalogue that fits and addresses the needs of an undergoing software development effort. Output Selected requirements pattern template Roles Requirements Engineer Criteria XT01 - Catalogue size: Large-sized catalogue XT02 – Expertise of requirements engineer: Mid-level expertise XT03 – Availability of tools (similarity calculation tool): Available Table 3. Method chunk C03: Selecting a requirements pattern template manually. ID C03 Goal Requirements engineers explore the catalogue using only their experience to select a requirements pattern template. Input 1) Available requirements pattern templates as a catalogue Activity Explore the available requirements patterns and manually select a requirements pattern template that fits and addresses the needs of an undergoing software development effort. Output Selected requirements pattern template Roles Requirements Engineer Criteria XT01 – Catalogue size: Small-sized catalogue XT02 – Expertise of requirements engineer: Senior-level expertise XT03 – Availability of tools: Not available 2.2 Chunks for Populating a Requirements Pattern Template Having selected a requirements pattern template, the next intention comprises populating it. This allows the stakeholders to customize the requirements pattern template with their feedback—e.g., expressing how data should be displayed, how data should be 4 Mosquera et al. 2025 stored, or how the process should be orchestrated, among others. As a result, the requirements engineer receives a populated requirements pattern template containing the customizations from stakeholders. This intention is also referred to as requirements extraction/creation [11] and requirements documentation [6]. After analysis, we identify strategies to achieve this intention, including filling the template with default values (C04), using an assistant to guide stakeholders on template customization (C05), or manually customizing the template. We consider that selecting one of these chunks will depend on the stakeholders’ involvement (XT04), the need for customization of the template (XT05), and the availability of dedicated tools (XT03). We summarize the chunks we have identified for populating requirements pattern templates in the following tables. Table 4. Method chunk C04: Populating requirements pattern template with default values. ID C04 Goal Requirements engineers populate a requirements pattern template with default values [15], requiring minimal involvement of stakeholders to customize the requirements pattern template. Input 1) Selected requirements pattern template 2) Set of default values for populating the template Activity Provide the required inputs from a requirements pattern template with a set of default values. Output Populated requirements pattern template Roles Requirements engineer Criteria XT04 – Stake holder involvement: Minimal involvement XT05 – Need of template customization: Low XT03 – Availability of tools (default values): Available Table 5. Method chunk C05: Populating requirements pattern template with an assistant. ID C05 Goal Stakeholders populate a requirements pat-tern template with the support of an assistant, iterating over the possible customizable inputs and getting recommendations while populating the template [20]. Input 1) Selected requirements pattern template 2) A template compatible assistant. Activity Load the selected requirements pattern template into the assistant. Review assistant’s suggested values for each required input from the requirements pattern template. Populate the inputs with values accepting or declining the assistant suggestions until all inputs have been populated with a value. Output Populated requirements pattern template Roles Stakeholder Criteria XT04 – Stake holder involvement: Moderate involvement XT05 – Need of template customization: Moderate XT03 – Availability of tools (assistant): Available The MARPa Method 5 Table 6. Method chunk C06: Populating requirements pattern template manually. ID C06 Goal Requirements engineers guide stakeholders to populate a requirements pattern template and verify the template based on their expertise, customizing the template and inputs as needed [11]. Input 1) Selected requirements pattern template Activity Explore the selected requirements pattern template together with a stakeholder. Provide manually and edit the template as required based on the feedback from the stakeholder. Template content can be changed on an ad-hoc manner to adapt as much as possible the content to the needs from the stakeholder. As soon as the stakeholder confirms the populated template fits the requirements, this activity ends. Output Populated requirements pattern template Roles Stakeholder and Requirements Engineer Criteria XT04 – Stake holder involvement: High involvement XT05 – Need of template customization: High XT03 – Availability of tools: Not Available 2.3 Chunks for Creating Software Models Having populated a requirements pattern template, LCNC developers can create software models into an LCNC tool based on the gathered data. This intention aligns with modules that expect input data from LCNC users and create software models, as presented in modelling assistance frameworks [7, 8]. After analysis, we identify strategies to achieve this intention, including using a template to model transformations (C07) or manually creating the software models relying on the experience of the LCNC developer. We consider that selecting one of these chunks will depend on how much customization is needed during software model creation (XT06), the expertise of the LCNC developer (XT07), and the availability of tools (XT03). We summarize the chunks we have identified for creating software models in the following tables. 6 Mosquera et al. 2025 Table 7. Method chunk C07: Creating software models by using template to model transformations. ID C07 Goal LCNC developers use automatic template-to-model transformation to create software models into an LCNC tool [15, 16, 20], similar to model-to-model and model-to-text transformations [1]. Input 1) Populated requirements pattern template 2) Template to model transformations Activity Load the populated requirement pattern template into a template to model transformation engine together with template to model transformations. Execute the transformation from the template transformation engine. Create the software models using the results from the transformations into an integrated LCNC tool. Output Created software model into an LCNC tool Roles LCNC developer Criteria XT06 – Customization needed during software model creation : Low XT07 – LCNC developer expertise: Mid-level expertise XT03 – Availability of tools (transformation engine and template to model transformations): Available Table 8. Method chunk C08: Creating software models manually. ID C08 Goal LCNC developers use their expertise and own interpretation to create soft-ware models into an LCNC tool based on a populated requirements pattern template. Input 1) Populated requirements pattern template Activity Analyze the populated requirements pattern template. Then, the LCNC developer transforms the populated requirements pattern template based on his/her experience—i.e., heuristically. Output Created software model into an LCNC tool Roles LCNC developer Criteria XT06 – Customization needed during software model creation: Low XT07 – LCNC developer expertise: Mid-level expertise XT03 – Availability of tools (transformation engine and template to model transformations): Available 2.4 Chunks for Refining Software Models As soon as LCNC developers create the software models, two scenarios can be considered: i) software models are ready, or ii) the software models require some refinement. In the first case, LCNC developers do not need to execute extra strategies. In the second case, they must refine the software models. This intention aims to improve a software model based on machine-based or human-based feedback. Refining software models aligns with modules that expect an LCNC software model and refine it by improving The MARPa Method 7 model consistency or suggesting model elements, as presented in modelling assistance frameworks [7, 8]. After analysis, we identify strategies to achieve this intention, including using in-LCNC-tool embedded feedback (C09), with model-based testing (C10), using model evolution tools (C11), and based on user’s feedback (C12). We consider that selecting one of these chunks will depend on the expected effort for gathering refinement feedback (XT08), the involvement of end-users (XT09), the LCNC developer expertise (XT07), and the tool availability (XT03). We show the chunks we have identified for refining software models in the following tables. Table 9. Method chunk C09: Refining the software models by using tool embedded feedback. ID C09 Goal LCNC developers use LCNC tool-embedded feedback such as lexical, semantical, and syntactical analyzers [25] to gather refinement feedback. Input 1) Software models in an LCNC tool 2) Embedded feedback from LCNC tools. Activity Identify the LCNC tool embedded feedback regarding the created software model. Analyze, apply, and follow the refinement feedback provided by the LCNC tool to resolve conflicts, errors, bugs, inconsistencies, or warnings present in the software model. Output Refined software model into an LCNC tool Roles LCNC developer Criteria XT08 – expected effort for gathering refinement feedback: Low XT09 – involvement of end-users: Minimal involvement XT07 – LCNC developer expertise: Mid-level expertise XT03 – Availability of tools (embedded feedback tools): Available Table 10. Method chunk C10: Refining the software models with a model-based testing tool. ID C10 Goal LCNC developers use model-based testing tools to gather feed-back regarding model validity—e.g., software model consistency [26, 27]. Input 1) Software models in an LCNC tool 2) Compatible model-based testing tool Activity Provide the software model into the model-based testing tool. Execute the model-based tests, e.g., intra/inter consistency tests between models and other artefacts such as code or other models. Refine the software models based on the refinement feedback provided by the model-based testing tool. Output Refined software model into an LCNC tool Roles LCNC developer Criteria XT08 – expected effort for gathering refinement feedback: Moderate XT09 – involvement of end-users: Minimal involvement XT07 – LCNC developer expertise: Mid-level expertise XT03 – Availability of tools (model-based testing tool): Available 8 Mosquera et al. 2025 Table 11. Method chunk C11: Refining the software models by using a model evolution tool. ID C11 Goal LCNC developers use model evolution tools to complement the software models into an LCNC tool—e.g., relying on suggestions for extra model elements [28–31]. Input 1) Software models in an LCNC tool 2) Compatible model evolution tool Activity Provide the software model into the model evolution tool. Request model evolution tool feedback, e.g., by requesting other model elements that may fit with the current software models in the LCNC tool such as attributes, entities, tables, relationships, processes, roles, among other model elements depending on the model under refinement. Refine the software model by accepting or declining the suggested evolutions from the tool. Output Refined software model into an LCNC tool Roles LCNC developer Criteria XT08 – expected effort for gathering refinement feedback: Moderate XT09 – involvement of end-users: Minimal involvement XT07 – LCNC developer expertise: Mid-level expertise XT03 – Availability of tools (model evolution tool): Available Table 12. Method chunk C12: Refining the software models based on user’s feedback. ID C11 Goal LCNC developers gather and interpret end-user feedback to refine the software models—e.g., a software usability study. Input 1) Software models in an LCNC tool Activity Gather feedback from end users to gather feedback regarding the software models, e.g., by executing a user interaction study such as codiscovery, thinking aloud, or interviewing. After analysis of the collected data, the LCNC developer refine the software models based on his/her interpretation about the collected feedback. Output Refined software model into an LCNC tool Roles LCNC developer Criteria XT08 – expected effort for gathering refinement feedback: High XT09 – involvement of end-users: High involvement XT07 – LCNC developer expertise: Senior-level expertise XT03 – Availability of tools: Not available 2.5 MARPa Method Chunk Extensibility Following SME principles [1], MARPa chunks can be extended through inheritance as shown in other SME proposals as SUPERSEDE [4]. All MARPa chunks can be extended and deeply specified depending on the tool or strategy at hand. This deeper specification allows to represent new context criteria, constraints, and dependencies between selected chunks when method tailoring. For example, chunk C01 select The MARPa Method 9 requirements pattern template using a classification schema can be deeply specified by the classification schema type to be used. One alternative as expressed in [5] is having an ISO-standard based classification schema such as the ISO/IEC 9126 for software quality assurance (later replaced by SQuaRE ISO 25000). Method engineers can then deeply specify a method chunk C01.a select requirements pattern template using the ISO/IEC 9126 classification schema, having the following changes from C01: Table 13. Method chunk C01.a: Selecting a requirements pattern template by using the ISO/IEC 9126 classification schema. The strikethrough text indicates content removed from the original text, while the green text represents additions made to extend the chunk. ID C01 Goal Requirements engineers filter the catalogue based on features [15], domains [16], and non-functional requirements [11] for quality assurance compiled in the ISO/IEC 9126 among other classification schemas, to select a requirements pattern template. Input 1) Classification schema based on the ISO/IEC 9126 2) Available requirements pattern templates as a catalogue Activity Using an ISO/IEC 9126-based classification schema filter the requirements pattern catalogue. First filter by the quality attribute (e.g., usability) and then, if needed, use sub quality attributes to filter again the catalogue (e.g., usability.attractiveness). Then select a requirements pattern template from the filtered catalogue that fits and addresses the needs of an undergoing software development effort. Output Selected requirements pattern template Roles Requirements Engineer Criteria XT01 - Catalogue size: Medium-sized catalogue XT02 – Expertise of requirements engineer: Mid-level expertise XT03 – Availability of tools (ISO/IEC 9126-based classification schema and compatible catalogue with the classification schema): Available 3 MARPa Process Map, Metamodel, and Context Criteria We propose the MARPa process map in Fig. 1Error! Reference source not found. together with a set of context criteria shown in Table 14. MARPa Chunks (C) vs Context Criteria (XT) Matrix.and metamodel in Fig. 2. The process map guides the composition of method chunks while context criteria support their selection by assessing their adequacy to the context at hand. MARPa metamodel, process map, and context criteria are extensible and tailorable .