Background: Several methodologies have been proposed since the first days of software development, from what is now named traditional/heavy methodologies, and later their counterpart, the agile methodologies. The whole idea behind agile methodologies is to produce software at a faster pace than what was considered with plan-based methodologies, which had a greater focus on documenting all tasks and activities before starting the proper software development. Problem: One issue here is that strict agilists are often against fully documenting the software architecture in the first phases of a software process development. However, architectural documentation cannot be neglected, given the well-known importance of software architecture to the success of a software project. Proposed Solution: In this article, we describe the past and current situation of agile methodologies and their relation to architecture description, as well as guidelines for future Agile Methodologies and Architecture Reconciliation. Method: We propose a literature review to understand how agile methodologies and architecture reconciliation can help in providing trends towards the success of a software project and supporting software development at a faster pace. This work was grounded in General Systems Theory as we describe the past, present, and future trends for rapid systems development through the integration of organizations, stakeholders, processes, and systems for software development. Summary of results: As extensively discussed in the literature, we found that there is a false dichotomy between agility and software architecture, and then we describe guidelines for future trends in agile methodologies and reconciliation of architecture to document agile architectures with both architectural decisions and agile processes for any system, as well as future trends to support organizations, stakeholders, processes, and systems.

In software engineering, there must be clarity in communication among interested parties to elicit the requirements aimed at software development through frameworks to achieve the behaviors expected by the software. Problem: A lack of clarity in the requirement-elicitation stage can impact subsequent stages of software development. Solution: We proposed a case study focusing on the performance efficiency characteristic expressed in the ISO/IEC/IEEE 25010 standard using Behavior-Driven Development (BDD). Method: The case study was performed with professionals who use BDD to elicit the non-functional requirements of a company that develops software. Summary of Results: The result obtained was the validation related to the elicitation of non-functional requirements aimed at the performance efficiency characteristic of the ISO/IEC/IEEE 25010 Standard using the BDD framework through a real case study in a software development company. Contributions and impact: The article’s main contribution is to demonstrate the effectiveness of using BDD to elicit non-functional requirements about the performance efficiency characteristic of the ISO/IEC/IEEE 25010 standard.

Background: The design of Autonomous Systems must consider multiple elements of the system, such as agents, physical objects and their software counterparts, control mechanisms, sensors, actuators, and other components. All these distributed elements in the environment make the necessity of creating multiple views for design, including system coordination, development, structural, and behavior views. Therefore, Software/Systems Architectures have been recognized as an important element in process development to manage the systems' complexity. Objective: The objective of this article is to describe a review of architecture characteristics, approaches, styles, and standards that are commonly considered for the development of autonomous systems. Method: First, we describe important elements of software architecture, as well as the standards used in this field. Then, we describe the types of approaches for architecture design. In addition, we provide a classification of software/systems architectures for autonomous systems. Results: As a result, we present a review on the Software/Systems Architecture description for Autonomous Systems. We also find that formal architecture standards are rarely considered in practice, and a large variety of nonfunctional requirements is mentioned. Conclusion: As autonomous systems deal with many components interacting with the real world, under certain quality constraints, considering trade-offs and decisions, software/system architectures are highly relevant for managing all this complexity. A list of main challenges for autonomous systems is described and then discussed according to a review of the literature. This review can be useful for professionals and researchers in identifying software/systems architecture as an important technical element for developing autonomous systems.