Goal-Oriented Requirements Engineering (GORE) supports the development team in identifying the requirements that the system must fulfil. Commonly applied during the initial stages of requirements gathering, it focuses on identifying the system's goals, presenting their decomposition as a means of ofering alternatives to satisfy them. Knowledge Acquisition in Automated Specification (KAOS) is a GORE approach that comprises a method, a software environment, and a modeling language. Modelling languages can be adaptable to various domains/application areas where the software will be developed. This way, extensions are proposed to adapt the modelling to the desired scenarios. These adaptations are referred to as extensions. KAOS has been extended to various areas, including security, adaptive systems, and aspects, among others. The creation of new KAOS extensions has been growing. It is expected to continue in the coming years, as it is necessary to adapt languages to the various existing contexts and those that emerge with the constant evolution in software development. Creating an extension is a complex task with inherent challenges, such as maintaining consistency between the developed and existing extensions. Given these facts, we recognise the need to support the creation of KAOS language extensions. This study aims to support the systematic creation of new KAOS extensions through a systematic process. The proposed process was used to create a new KAOS extension to represent accessibility concepts, which proved valid for this purpose. Finally, the PRAOS process was evaluated by KAOS extension specialists through a qualitative study.
Goal-Oriented Modelling Languages visually represent the system to be developed and are used in the
early stages of development to elicit and specify application requirements. Errors in Requirements
Engineering (RE) can lead to project failure if they deviate from expected outcomes [
KAOS [
The evolution of software development, driven by new technologies and paradigms, has necessitated the extension of KAOS to ensure a faithful and precise specification of requirements, efectively bridging this gap. These extensions aim to enable a more precise specification of systems to be developed. Thus, we argue that KAOS has been extended and will be continue to be extended. However, these extensions have been proposed in an ad hoc way.
This work supports the systematic creation of KAOS extensions through a systematic process.
Processes provide consistency and structure, essential for successful project execution and knowledge
transfer [
This paper is organized as follows: Section 2 presents the background, Section 3 shows related work, Section 4 details our process and its validation, Section 5 evaluates the process through interviews, and Section 6 concludes and suggests future work.
Model-based engineering (MBE) can be defined as a process in which software models play an important
role but are not necessarily critical artefacts of the development [
In this context, modelling language is defined by its abstract syntax (i.e., through a metamodel and
wellformedness rules/semantics) and concrete syntax. According to Kelly and Tolvanen [
We typically identify various domain rules, constraints, and consistency requirements that a language
should adhere to. These rules obviously need to be defined too. Having rules in the language provides
several benefits, including early error prevention, guidance towards preferable design patterns, checks
for completeness by informing about missing parts, minimization of modeling work efort through
conventions and default values, and consistency of specifications [
Modelling language designers use abstract syntax and well-formedness rules as the starting point for
concrete syntax definition [
Brambilla et al. [
KAOS [
KAOS has been extended to represent new constructs, adapt existing ones, or remove them. From this need arises the creation of new KAOS extensions, which involve adapting an existing extension to new scenarios, such as new representations and specific functionalities tailored to the particular application domain.
A Systematic Literature Review (SLR) of KAOS extensions [
The first KAOS extension identified by [
An analysis of the extensions revealed that almost half of the papers (48%) provide complete definitions for all introduced concepts, while 44% ofer partial definitions, and 8% do not present any definition. Regarding syntax level, most extensions (72%) focused only on concrete syntax , 24% addressed both abstract and concrete syntax, and 4% only abstract syntax. Furthermore, most abstract syntax extensions (92%) are conservative, maintaining all KAOS constructs. As for new constructs, 62.44% were applied to nodes, and 37.56% to links. A crucial point is that only 35% of the extensions have CASE tool support, which may limit their adoption and practical application. No standardized extension mechanisms were identified for KAOS. These data highlighted the need to support the proposal for the next KAOS extensions.
Gonçalves et al. [
Fowler [
Braun et al. [
The proposal for a process to support the creation of new KAOS extensions is based on the PRISE
process by Gonçalves et al. [
This section will describe the steps and central adaptations made to PRISE to adjust it to the creation of KAOS extensions, resulting in a new version called PRAOS (PRocess to support kAOS extensions).
The adaptation process followed these steps: First, we created a spreadsheet containing all PRISE sub-processes, tasks, artefacts, and gateways. Each element of this spreadsheet was classified as "remove", "keep", or "keep adapted". When necessary, the adaptations were detailed in the spreadsheet itself. This analysis was supervised by a researcher with experience in extensions and required five review/correction cycles to complete a spreadsheet1.
After identifying the changes in the spreadsheet, these changes were implemented in Bizagi’s PRISE project. PRISE was initially modelled in BPMN (Business Process Modelling and Notation), and we decided to keep the PRAOS modelling in BPMN as well, given that this language is widely used for modelling business processes. This stage was also supervised by a researcher with experience in extensions, with five review/correction cycles of the modelled process.
The changes can be categorized into two classes: more general and simple changes, which afect a set of parts of the process (such as changing the name from PRISE to PRAOS), and more specific changes (such as replacing the list of iStar constructs with KAOS constructs in the checklist for verification of completeness, consistency, and conflicts). We made several general changes to the PRISE process to adapt it to KAOS, resulting in significant modifications to the sub-processes. Most of these changes involved replacing references to iStar with KAOS, which essentially implied changing the terminology and concepts associated with modelling. Therefore, most changes consisted of updating the terms and names related to the new modelling language. Initially, we could reuse 34 PRISE elements (tasks/artifacts/gateways) without the need for significant adaptations since these elements were already organized in a general way, including gateways and initial and final states. Next, we analysed the PRISE structures that were compatible with PRAOS but required minor adjustments, such as replacing terms related to the KAOS language. These adjustments represented most of the modifications made from PRISE, accounting for 96 changes considered simple. Finally, we addressed 27 more specific adaptations. We can mention as examples of these adaptations, the change of the iStar metamodel to the KAOS metamodel, the development of a catalogue of KAOS extensions, a modelling tool to support KAOS extensions, the list of the experts in KAOS extensions, the adaptation of iStar extensions guidelines to KAOS, and the introduction of LLMs usage in some steps of the process.
This Section details PRAOS2. Additionally, we presented parts of a new KAOS extension3. The proposed extension focuses on representing accessibility concepts in KAOS modeling.
PRAOS consists of five subprocesses and one task that occurs in parallel to three subprocesses. Figure
2 presents the primary process. It is based on a set of nine (9) guidelines adapted from a previous study
[
In the following, we describe the adapted and recommended procedures for creating a KAOS extension proposal.
G1: Preserving the original syntax of the KAOS language is essential. It is recommended that all nodes and links of the original syntax be maintained in the extension. In other words, extensions that remove all standard constructs, those that are not conservative, are generally discouraged and considered examples not to be followed.
G2: Extensions must be consistent, complete, and conflict-free, following a defined process or method for their creation. Currently, the creation of extensions for KAOS has been carried out haphazardly without centralizing existing information about the modeling language.
G3: Conduct a systematic review of the literature to identify all existing extensions and assess the absolute need to create a new extension or take advantage of an existing one. It is essential to consider including a KAOS expert in the development process and modeling several systems in the desired area to gain a more comprehensive understanding of the domain that requires the extension.
G4: Describe the extension concepts clearly and objectively, seeking to minimize the possibility of divergent interpretations as much as possible.
G5: Consider proposing both the abstract and concrete syntax of the extension, as they can complement each other.
G6: Seek to maintain a clear and direct reformulation, focusing on consistency between the two syntaxes.
G7: Establish a relationship between the constructs inserted in the extension and those existing in the original KAOS language.
G8: Seek to define new extensions with the smallest possible number of new constructs, making the most of existing constructs and creating only the minimum necessary to adapt to the new domain.
G9: Try to create simple representations that can be understood without the need for specific tools, thus ensuring ease of use.
The following sections provide a detailed description of each of these sub-processes and their related artifacts.
This subprocess aims to verify the need to propose a new KAOS extension and establish the initial requirements for such an extension. Artefacts used by subprocess 1: List of references and contacted researchers, List of concepts to be introduced, Modelling and observations, List of experts in KAOS extensions, List of related KAOS extensions and Extension specification (analysed). Figure 3 presents sub-process 1.
Initially, the rationale for the extension proposal is analysed, and the new concepts to be introduced are identified. It generates the Extension specification [Analysed]. Subsequently, a thorough study of the application area is conducted to identify specific requirements and gaps that the standard KAOS cannot address. This involves a literature review and, if necessary, consultation with domain experts. A review is not required when it relates to the practical aspects of KAOS. Based on this analysis, the new concepts that the extension should encompass are identified. These concepts may relate to the application domain or more general aspects of KAOS.
To validate the need for the extension, five sequential tests are performed. The first test assesses
whether the application domain exhibits problems that cannot be modelled using standard KAOS.
Subsequent tests evaluate the feasibility of modelling the new concepts using existing KAOS and
identify the limitations. Two tests involve consulting with experts in the domain and KAOS extensions.
We suggest that when these experts are not available, LLMs (such as ChatGPT4 and Gemini5) can be
used to mitigate issues. Questions can be made to these LLMs about the list of new constructs and
issues related to KAOS constructs. Task 1.10 is related to the identification of existing KAOS extensions;
4https://chatgpt.com/
5gemini.google.com
it can be performed based on the support of the catalogue of KAOS extensions6 [
According to W3C [
After identifying the context and need to create the extension, a (non-systematic) literature review was carried out. Thus, based on these steps, the following concepts were identified: Accessible Agent, Accessibility Requirement, Accessible Operation, and Accessible Domain Property.
It was not necessary to consult domain experts or an LLM. We modeled an example of an accessible system using KAOS (See the complete extension specification) and identified the need to represent accessibility concepts with a specific syntax to highlight them in KAOS models. It was not necessary to consult KAOS experts, since the author is an expert in KAOS extensions. We did not nfid any related extension in the KAOS extension catalogue.
This sub-process involves several tasks and artefacts, with the Extender and the Expert in KAOS extensions as key participants. The primary artefact generated by this sub-process is the "Extension Specification [Concepts Described]". Artefacts used by subprocess 2: Extension specification (concepts described); Modelling and observations; List of relations between KAOS original constructs and extension constructs; List of ideas to be introduced and list of concepts to be reused. Figure 4 presents sub-process 2.
The initial task involves searching and selecting reusable constructs. The Extender accesses the KAOS extensions catalogue to identify and choose the constructs previously identified in the "Extension Specification [Analysed]". Next, the process focuses on describing the extension’s concepts in detail. This includes defining the list of constructs introduced or reused within the KAOS extension.
Subsequently, the Extender analyzes how to integrate these new extension constructs with the existing KAOS constructs. If any integration challenges arise, the Extender consults with experts in KAOS extensions. The Expert in KAOS extensions then provides guidance and resolves the integration issues. LLMs can be helpful in this context, clarifying issues related to the meaning of constructs and their integration with KAOS default constructs.
Finally, the "Extension Specification [Concepts Described]" is generated by combining the "Extension Specification [Analysed]" with the artefacts produced in this sub-process: the "List of Constructs to be Reused" (including their definitions) and a list defining the relationships between extension and KAOS constructs. This sub-process concludes with a complete description of the KAOS extension concepts.
This sub-process, initiated upon confirmation of the need for extending KAOS in sub-process 1, focuses on defining the new concepts that will be introduced into the KAOS modelling language. The Extender is the primary actor in this phase. Before proceeding, the Extender should carefully review the guidelines provided by KAOS experts for developing extensions. Artefacts used in subprocess 3 include the KAOS metamodel, Extension metamodel, validation rules, Extension specification (Developed), and Checklist of problem verification. Figure 5 presents sub-process 3.
The first step involves defining the metamodel for the extension. This includes determining the new
concepts, their attributes, and their relationships with existing KAOS constructs. The Extender should
refer to existing KAOS metamodels, such as those presented by Lamsweerde [
Next, the Extender defines validation rules for the extension. These rules address constraints that cannot be directly represented within the metamodel. For example, if certain combinations of constructs are not allowed, the Extender would define rules to enforce these constraints.
Concurrently, the Extender defines the concrete syntax for the extension. This involves determining
the graphical representation of the new extension constructs. One approach is to experiment, as
Caire et al. [
We suggest using LLMs (such as ChatGPT and Gemini) to mitigate issues with the metamodel definition and concrete syntax. LLMs can contribute to clarifying the representation of a new element in the KAOS metamodel. LLMs can help indicate symbols to represent the new constructs.
Once the proposal for concrete syntaxes is finalized, a check is performed to ensure the completeness, consistency, and absence of conflicts within the extension. This analysis covers the completeness of the extension definition (including concepts, abstract syntax, and concrete syntax), consistency between concepts, abstract syntax, and concrete syntax, the absence of nodes and links that conflict with the standard KAOS syntax, the occurrence of conflicts between new constructs and existing KAOS constructs, and the correctness of the representation of standard KAOS constructs within the extension. The Extender should use a checklist to verify the occurrence of these potential problems and correct any issues identified.
If feasible, the extension should be supported by a modelling tool. To support the extension, the Extender should analyse the feasibility of using existing KAOS modelling tools (such as Objectiver7 and DSM3-KAOS8). Additionally, we proposed KAOS4Ext9, a new web modelling tool with support to add the new extensions constructs’ to KAOS models. This new tool enables the addition of new graphical or textual representations to create new nodes and links. 7https://objectiver.com/index.php?id=4 8https://www.cin.ufpe.br/ jhcp/dsm3goals/kaos.html 9https://kaosforge.com.br/
The Extender should test the modelling tool to ensure it allows and forbids the expected operations within the extension. Finally, if a suitable tool is identified, the Extender should make the tool available to other users by publishing it in a repository such as GitHub. This revised version maintains the core information and ideas while presenting them in a more continuous and readable format.
Regarding the new KAOS extension for accessibility, we included the new constructs in the KAOS metamodel by specialisation of existing Agent, Requirement, operation, and domain property constructs. The extension metamodel can be found in the complete extension specification. It was not required to propose validation rules.
The concrete syntax represented the constructs through textual stereotypes associated with their specialised constructs. The extension impacts the four (4) KAOS diagrams in which the base constructs appear. We analyzed the extension using the checklist for verification of problems and did not find any issues with completeness, consistency, or conflicts. Figure 6 presents an example of a goal model created with the proposed extension, in which we can identify accessible agents, accessible requirements, and accessible domain properties.
The sub-process presented in Figure 7 comprises three pairs of analysis and the corresponding corrections for the KAOS extension. Initially, the Extender conducts the first validation using the proposed extension to model a system. The Extender should select non-trivial and realistic examples to demonstrate the extension’s capabilities. This process includes documenting the steps required to use the extension efectively. The necessary adjustments are made if the Extender identifies any corrections or improvements during this phase, such as missing relationships between concepts. In the second pair, the KAOS extension is submitted to domain experts (in KAOS extensions and the application domain) for their analysis and feedback. Given that LLMs can be utilized during the process, we emphasize the importance of evaluation by at least one KAOS expert to verify the proposed KAOS extension and identify potential errors. The third pair focuses on evaluating the efectiveness of the extension. This can be achieved through various methods, including experiments, qualitative studies, or surveys.
If the evaluation identifies any areas for improvement, the necessary corrections are applied. Artefacts used in subprocess 4: • List of KAOS experts: List of the foremost KAOS experts to be contacted if there is a need to clarify issues. • Extension specification (Validated/Evaluated): Generation of the extension specification. • Problem verification checklist: Checklist with the main problems to ensure that recognised problems are not present in the extension proposal.
Regarding the extension proposed with PRAOS, we modeled the accessibility for people who are blind as an example. Figure 6 presents the goal model to our example. Additionally, a survey was conducted to evaluate the proposed extension among researchers in the area of human-computer interaction and assess their opinions on the proposed extension. The study included 20 participants from the Brazilian HCI community. The survey addressed issues related to the need to create the proposed extension, its usefulness, feasibility, impact on the HCI community, and recommendations for its use. The possible responses ranged from one (1) to five (5) on a Likert scale. Responses ranged from three (3) to five (5) for all items evaluated, demonstrating evidence of community acceptance of the proposed extension. The detailed evaluation can be found in the complete extension specification.
This task involves identifying the necessary constructs for the KAOS extension that were not initially identified in the first subprocess and were subsequently discovered in subprocesses 2, 3, or 4. When new constructs are identified, it becomes necessary to iterate through subprocesses 2, 3, and 4 again to incorporate them into the extension. We did not find any additional constructs during the proposed extension for accessibility.
This sub-process intends to increase the visibility of new extensions within the research community. Artifacts used in sub-process 6 are the List of KAOS experts and the Extension specification (validated/evaluated). This sub-process begins with updating the KAOS extension catalog. The Extender links the related publication or updates the existing Extension Specification.
Additionally, the Extender is required to provide essential information about the extension, including title, abstract, application area, extension base, level of extension, compatibility between metamodel and concrete syntax, metamodel completeness, concept definitions, proposed construction method, reasoning approach, tool support, validation methods, validation rules, and added constructs.
If experts in KAOS extensions participated in developing the new extension, they would endorse it. Otherwise, the Extender notifies relevant experts about the new extension. The Extender should contact at least one expert in KAOS extensions to inform them about including the new extension in the catalog. These contacted experts can endorse the KAOS extension if they deem it well-defined.
In parallel, the Extender actively seeks to publish the KAOS extension. This may involve presenting the extension at conferences, publishing it in journals, or disseminating it through blogs or discussion lists. Finally, the sub-process concludes when the KAOS extension has been published and endorsed. Consequently, the extension proposal is considered complete.
An expert in KAOS extension was part of the proposal for the new KAOS extension. He endorsed the new KAOS extension. Finally, this paper is the final step in this proposal, as one of its goals is to publicize the new KAOS extension.
We conducted a qualitative study based on semi-structured interviews to identify the perspectives about PRAOS from researchers who have proposed KAOS extensions. An interview script containing opened questions was developed and validated by a researcher experienced in goal-oriented modelling languages and extensions. We also conducted a pilot study with two undergraduate students in computing from the Federal University of Ceará, who had no prior knowledge of PRAOS or KAOS, and a pilot study with a master’s student in computing who was familiar with KAOS extensions. These previous analyses of the script helped to improve it. The pilot data were not considered in the study. The final version of the interview script is available in Table 1. Participants watched a video about PRAOS in Portuguese, English and/or French after question 2.
The universe of this research (population) comprises authors of KAOS extensions. Thus, our universe (population) is 113 authors of KAOS extensions. We selected a sample of 13 researchers with more experience in KAOS extensions based on the analyses presented in the KAOS extensions RSL (Section 4). We obtained confirmation of participation from five (5) members of the sample, who are our participants.
The participants are geographically distributed: one (1) from Brazil, two (2) from Italy, one (1) from Portugal, and one (1) from France. The five (5) participants have a PhD, four (4) professors, and one is a technology director and professor at a company. Regarding the experience with KAOS, three participants used KAOS for 8, 9, and 15 years, respectively. The other two commented that their experience was specific to the model concepts of a particular domain. Regarding the number of extensions each participant produced, only P2 proposed two extensions, while the others produced only one (1).
The interviews were conducted via Google Meet, and each participant was interviewed individually.
Each interview was recorded with the participant’s consent. Each interview had an average duration of
30 minutes. The qualitative data from the interviews were then analysed using Merriam’s [
No participant reported knowing of any other method to extend KAOS. When asked about PRAOS, P5 commented: "PRAOS covers all the steps necessary to carry out an extension systematically and produce consistent quality results. The process is also quite complete".
Regarding the level of efort and dificulty in understanding the process, the participants found it easy to comprehend. All participants commented that they would use the method with changes. The main modifications mentioned were not consulting experts and skipping some steps, as seen in P2’s comment: "I think it is possible to remove the expert from the group completely." Although some participants commented on the dificulty of getting experts in touch, one participant highlighted the value of this step.
The value observed in the use of PRAOS is not only due to the rigorous methodology, according to some participants, but also because there are certain domains in which this rigor is essential, such as in security. A general analysis of the interview’s points to predominantly positive feedback, with several essential suggestions and observations that could significantly contribute to improving the process. Here are the main points highlighted: • Overall Approval of the Process: The participants expressed satisfaction with the process developed for creating new KAOS extensions. They considered the process well-structured and comprehensive, with a straightforward approach to defining and implementing new constructs. • Relevance of Adapted iStar Guidelines: It has been widely acknowledged that adapting the iStar guidelines for KAOS is a valuable addition. Participants believe that these guidelines help create a solid foundation for extension development by aligning the process with established and well-known practices in goal-oriented modeling. • The usefulness of Guidelines and Structure: The PRAOS structure and included guidelines were considered appropriate and helpful. Participants appreciated the organization of the process into clear sub-processes and the detailed steps that ensured the efective creation of extensions. • Adjustments to the Applicability of the Guidelines: Some participants suggested adjustments to the adapted guidelines to better reflect the particularities of KAOS. Although the iStar guidelines were well adapted, there was a recommendation to further fine-tune the policies to fit the specific context and needs of KAOS. • Inclusion of Practical Examples: It was suggested that including practical examples of how the new constructs were applied in real cases would clarify the practical application of the guidelines and facilitate understanding. • Expert Support and Collaboration: The researchers highlighted the importance of continued collaboration with experts and suggested creating a forum or discussion group to promote the exchange of knowledge and experiences among KAOS extension developers.
In this section, we describe the threats to Criterion, Construct, Face, and Content validity, as outlined
by Kitchenham and Pfleeger [
Criterion Validity: We identified a previous qualitative study (Gonçalves et al., 2020) with a similar
objective. However, the survey by Goncalves et al. [
The KAOS modelling language has been widely used and extended since its creation in the 90’s. However, these extensions were developed non-systemically, resulting in problems such as specification of the extension only at the concrete syntax level, inconsistency between syntaxes, and lack of support from CASE tools. The process to support the creation of KAOS extensions was proposed based on an existing method for another goal-oriented requirements language, the PRISE process. With the adaptations ready, the new process, called PRAOS, outlines the key characteristics of creating KAOS extensions. We then proceeded to validate PRAOS. To this end, a new KAOS extension was created using PRAOS as a base. The result was an extension aimed at supporting accessibility requirements modelling. Finally, we performed a qualitative study with researchers experienced in KAOS extensions.
As future work, we propose a tool to support the use of PRAOS and another to facilitate the application and modeling of the new constructs proposed by the extension. This work is supported by NOVA LINCS (UIDB/04516/2020) with the financial support of FCT- Fundação para a Ciência e a Tecnologia, through national funds
During the preparation of this work, the author(s) used Gemini and Grammarly in order to: Grammar and spelling check, Paraphrase and reword. After using this tool/service, the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content.