## 2 Related Work
This combination enables the development of an architecture model, which includes structural, data, behavior, and capability perspectives. The approach facilitates the iterative model development and allows one to shift the perspective of an Agile team towards MBSE, enabling the tracing of requirements and user stories between various perspectives and iterations of the model. It also supports the development of documentation that is especially relevant to government agencies. The introduction of a more structured approach, be it through modeling or employing various techniques for capturing, refining, and reconciling requirements involving different stakeholders and business analysts, allows knowledge gaps to be captured, and requirements to be validated, reconciled, and aligned [12; 13]. The different perspectives provided by different people, and in some cases the use of different notations, allow us to develop a clearer picture and a more comprehensive backlog [2; 12; 13; 18]. Once a comprehensive backlog is formed, albeit one that is not entirely detailed, most high-level requirements should be present and can be used in the scope estimation process. In Agile, not only requirement elicitation, but also scope and effort estimation present a unique set of challenges, especially in dealing with evolving incomplete requirements [15; 23]. As the topics of effort, scope, cost, and size estimation are closely related, and the terms scope estimation and effort estimation are often used interchangeably, we analyzed research on any of these topics in the area of Agile software development, especially its early phase. Precise estimation is challenging due to the requirements' variability, as the backlog may not be complete. Research on the introduction of machine learning techniques in scope estimation is underway; e.g., ref. [26] introduces the use of the GPT-2 pre-trained model for estimating the effort (in Story Points) required to implement the product backlog, but is intended primarily to be used during sprint planning. The analysis on improving expert-based methods [27] is also relevant, which determined that factors such as developer knowledge, experience, and the complexity and the impact of changes on the system directly affect the precision of effort estimation. The incorporation of models can be also used in estimating the effort and scope. The use of models is more prevalent in development practices employing a more robust documentation, such as COSMIC [20; 21], Use Case Points [30; 31], or Function Points [32]. COSMIC can be used to derive functional size measures from UML software artifacts, such as Use case model, Activity, Sequence, Class, Package, and Component diagrams [20]. In approaches combining Agile and COSMIC methods, there are also proposals to derive COSMIC metrics from user stories [21]. The Use Case Points-based method Know-UCP [30] utilizes the UML Use case model as a basis for deriving Use Case Points from UML diagrams to estimate the size of the software. Use Case Points can even be adapted to the development of IoT systems [31]. Function Points are another metric used to determine the size of software, and there exist approaches based on Function Points, such as [32], which heavily rely on modeling. The analyzed approaches apply these estimation techniques during the development process to obtain more accurate measurements of the remaining effort and scope of the project. Additionally, proposals exist that use models in estimation and are tailored for specific stages of software development, e.g., testing the effort of object-oriented systems can be determined using UML Class diagrams in [33]. As testing efforts can be determined early, early scope estimation is extremely beneficial to determine scope before committing to the project. In the project bidding, which is an early phase of the project, the estimation of the scope is a crucial step [34; 35].