A Compliance Analysis of Agile PBB Method Practices with the

Expected Results of the Requirements Engineering Process of

the MPS.BR Maturity Model

Jamilli Ynglid Carmo da Cunha

, Sandro Ronaldo Bezerra Oliveira

and Fábio Aguiar

Graduate Program in Computing, Institute of Exact and Natural Sciences, Federal University of Pará, Belém, Pará, Brazil

Accenture Brasil, FIAP, São Paulo, Brazil

Keywords: Software Requirements Engineering, Product Backlog Building, MPS.BR.

Abstract: The Brazilian software market has shown significant growth, with a 7.9% increase in 2022, as indicated by

the Brazilian Association of Software Companies. To meet the growing demand for high-quality technological

solutions, many companies have adopted agile methodologies. However, the adoption of these methodologies,

especially in requirements engineering, presents significant challenges, since this is a fundamental area for

the final quality of software. This paper proposes an analysis of adherence between the agile Product Backlog

Building (PBB) method and the Expected Results of the Requirements Engineering Process of the MPS.BR

(Brazilian Software Process Improvement) model. The objective is to evaluate how the PBB meets the

rigorous criteria established by the MPS.BR to obtain quality certification. The analysis revealed that, of the

seven Expected Results, four were partially met and three were not met, highlighting the need for adjustments

to the PBB method so that it can fully satisfy the MPS.BR requirements and allow companies to achieve

certification without compromising the agility of their processes.

1 INTRODUCTION

The Brazilian software market has shown significant

growth, with a 7.9% increase in 2022, as indicated by

the Brazilian Association of Software Companies

(ABES, 2023). This growth reflects the strategic

importance of the sector and the increased demand for

high-quality technological solutions. To meet this

demand, many companies have adopted agile

methodologies, which emerged as an alternative to

traditional approaches, which are inadequate to deal

with rapid technological evolution (Larman, 2004).

According to Silva and Oliveira (2020), agile

methods emerged as an alternative to minimize some

of the problems of traditional approaches. Among

these problems, issues related to requirements

engineering stand out, such as lack of stakeholder

involvement, excessive changes in requirements, and

poor specification of requirements, among others.

The adoption of these methodologies brings

challenges, especially in the requirements

https://orcid.org/0000-0002-0426-0606

https://orcid.org/0000-0002-8929-5145

https://orcid.org/0009-0001-7831-5788

engineering area, which is fundamental to the final

quality of the software developed.

Silva and Oliveira (2020) mention two studies.

One of them states that around 21% of the main

failure factors in software projects are related to

requirements, which have a direct impact on the

quality of the final product. In the other study

mentioned, more than 100 software development

projects were analyzed, and it was concluded that 35%

of the requirements of these projects changed, 65% of

the features described by the requirements are never

or rarely used, and around 50% of the team's time is

spent on requirements, architecture and product

specification.

MPS.BR, the Brazilian model for improving

software processes, establishes strict guidelines for

creating high-quality software. This model is widely

recognized and adopted by the software market,

including the Requirements Engineering process,

whose objective is to define, manage and keep the

requirements of stakeholders and the product up to

288

Carmo da Cunha, J. Y., Oliveira, S. R. B. and Aguiar, F.

A Compliance Analysis of Agile PBB Method Practices with the Expected Results of the Requirements Engineering Process of the MPS.BR Maturity Model.

DOI: 10.5220/0013554300003964

In Proceedings of the 20th International Conference on Software Technologies (ICSOFT 2025), pages 288-295

ISBN: 978-989-758-757-3; ISSN: 2184-2833

date, ensuring that inconsistencies between

requirements, plans and work products are identified

and addressed (Softex, 2024).

However, agile methods such as Product Backlog

Building (PBB), although innovative, do not fully

meet the criteria established by MPS.BR. According

to Cunha and Oliveira (2022), PBB facilitates the

collaborative understanding of requirements, but

when used in isolation, it does not allow companies

to achieve MPS.BR certification. This limitation

raises the question of how companies can adapt their

agile practices so as not to compromise quality and

still obtain certification.

The importance of this research is justified by the

constant search by organizations for methods that

increase the efficiency and quality of software

development, especially in an environment where

agility and precision are crucial to the success of

projects (Sommerville, 2015).

In this context, it is valid to establish a relationship

between the MPS.BR quality model and existing

agile methods. The objective of this paper is to

perform an adherence analysis between the Expected

Results of the Requirements Engineering Process

(REQ) of MPS.BR and the agile PBB method, that is,

to analyze how the PBB meets the REQ expected

results. Among the results of this adherence analysis,

four of the seven Expected Results were partially met

and three were not met. A more detailed description

can be found in Section 4.

This paper is organized as follows: Section 2

describes the background, Section 3 presents the

results obtained in the adherence analysis, Section 4

presents the evaluation of the analysis, and, finally,

Section 5 presents the conclusions of this research.

2 BACKGROUND

This section addresses a general understanding of the

method and model adopted in this research.

2.1 MPS.BR (Brazilian Software

Process Improvement)

According to Softex (2024), MPS.BR, Brazilian

Software Process Improvement, is a program that

began in 2003 with the support of the Ministry of

Science, Technology and Innovation (MCTI) in

Brazil and seeks to improve the development of

software, services and human resource management

practices in the ICT (Information and

Communication Technology) industry. “The

objective of the MPS.BR program is to increase the

competitiveness of organizations by improving their

processes” (Softex, 2024, p. 3).

MPS.BR focuses on process management,

indicating what the organization must do to achieve

the expected results of the model, without detailing

the step-by-step tasks. The model presents maturity

levels ranging from level G to A, whose requirements

are cumulative from the lowest level to the highest

level. Each maturity level is composed of a set of

processes (which are the areas of software

engineering), which have expected results (which are

the requirements that a company must meet to

achieve the objective of a process).

In this study, the MPS General Software Guide

(MR-MPS-SW) is used, which aims to implement

software engineering principles in a way that is

appropriate to the context of companies, in

accordance with international approaches for

defining, evaluating and improving software

processes. Likewise, in this work, the Requirements

Engineering process is used, which establishes the

process of defining software requirements, which

involves eliciting, modeling and analyzing.

“The purpose of the Requirements Engineering

process is to define, manage, and maintain up-to-date

stakeholder and product requirements, ensuring that

inconsistencies between requirements, plans, and

work products are identified and addressed” (Softex,

2024, p. 22). An expected result refers to the

objectives specific and measurable that an

organization must achieve when implementing a

process to the MPS.BR model. The expected results

of the Requirements Engineering process are

described below.

REQ 1 - The needs, expectations and constraints

of the stakeholders, both in relation to the product

and its interfaces, are identified and the

understanding of the requirements is confirmed: in

this expected result, the initial contact with the

customer and the identification of their needs occurs.

Based on these needs, the product's features are

defined. The customer's expectations reflect the

desired ideal scenario, generally related to the product

quality and performance. Constraints refer to the

limitations imposed by the solution, such as

compatibility with specific operating systems.

REQ 2 - Requirements are specified, prioritized,

refined, allocated for implementation and kept up to

date based on the identified needs, expectations and

constraints, which includes the specification of

operational concepts, scenarios and internal and

external interfaces: this step involves translating the

customer's needs into a technical language, covering

the definition, prioritization, refinement, allocation

and maintenance of requirements, based on the needs,

expectations and constraints identified in REQ 1. It

includes the specification of operational concepts,

A Compliance Analysis of Agile PBB Method Practices with the Expected Results of the Requirements Engineering Process of the MPS.BR

Maturity Model

289

scenarios and internal and external interfaces. An

interface is the means by which communication

occurs between two distinct parts of a system that

cannot connect directly. Operational concepts are

linked to the prototyping of requirements, which can

be demonstrated by means a BPMN (Business

Process Model and Notation) diagram, illustrating

how requirement steps are operationalized. A

scenario is a sequence of events that can occur during

the use of the product.

REQ 3 - The commitment of the technical team to

the implementation of the requirements is obtained:

this expected result refers to the commitment of the

technical team to the implementation of the

requirements, evidenced by meeting minutes, emails

or other appropriate documentation methods.

REQ 4 - Bidirectional traceability between

project requirements, activities and work products is

established and maintained: a system must be

established and maintained to track the relationship

between requirements and work products in a

software project, ensuring that each requirement is

linked to the corresponding work products and vice

versa. This process is crucial to assess the impact of

changes to requirements and manage changes.

REQ 5 - Plans, activities and related work

products are reviewed to identify and address

inconsistencies in relation to requirements: it is

essential to ensure that all project elements are

aligned with the defined requirements, performing

reviews, monitoring and control of the project, and

implementing corrective actions whenever necessary.

Whenever there are changes in the requirements, it is

necessary to verify that the other project work

products are consistent with these changes.

REQ 6 - Requirements are understood and

analyzed to ensure that they are necessary and

sufficient and to balance the needs of stakeholders

with the existing constraints: this expected result

emphasizes the importance of understanding and

analyzing the requirements to ensure that they are

clear, necessary and sufficient, balancing the needs of

stakeholders with the existing constraints. It is

mandatory to present evidence to prove these points.

Balancing means reviewing, improving and evolving

the product so that, each time this procedure is

executed, a new version of the product is created.

REQ 7 - Requirements are validated: validation

verifies that the requirements meet the customer's

needs, ensuring that the project team and stakeholders

share a common understanding of these requirements.

This expected result requires a more specific and

descriptive validation method, such as Use Case

Analysis, Prototyping, among others.

2.2 PBB (Product Backlog Building)

According to Aguiar and Caroli (2022), Scrum is the

most widely used agile framework for building

products. “However, the Scrum framework does not

define how to build the backlog. This is why PBB

complements Scrum, helping teams to develop and

create an effective Product Backlog” (Aguiar e Caroli,

2022, p. 35).

There are three fundamental aspects when we talk

about backlog (Schwaber and Sutherland, 2020): (i)

the product backlog is an ordered and emergent list of

what is needed to improve the product, (ii) the

backlog is the only source of work performed by the

Scrum team, and (iii) the Product Owner is

responsible for effectively managing the backlog.

According to Aguiar and Caroli (2022), the main

objective of Product Backlog Building (PBB) is to

help build and refine the Product Backlog

collaboratively. This method promotes a shared

understanding of the product among all those

involved and prepares the backlog for the team's agile

and effective work, using the PBB Canvas as a

facilitation tool. "PBB clarifies and prioritizes user

stories and items to be added to the Scrum team's

backlog" (Aguiar e Caroli, 2022, p. 46).

According to Aguiar and Caroli (2022), the

benefits of the PBB method include: (i) it helps to

build and refine a backlog in an effective and

collaborative way, (ii) it builds a shared

understanding of the customer's business, facilitating

the discovery and understanding of the product, (iii)

it describes the user's experience with the product, (iv)

it facilitates the discovery and writing of the user

story, (v) it defines a minimum of alignment and

initial planning, and (vi) it produces a Product

Backlog fully aligned with the customer's needs.

“The PBB method uses Canvas as a facilitation

tool. It provides a simple and easy-to-understand flow,

which makes it easier to understand the customer's

needs and build the product backlog” (Aguiar e Caroli,

2022, p. 51). Aguiar and Caroli (2022) state that

building a backlog in PBB should follow the

following flow:

1. Contextualize the Product: it is essential to

clarify and understand what the product is, identify

the problems and challenges that need to be addressed,

and highlight expectations, in addition to clarifying

the desired objectives. To do this, the product name,

problems and expectations of stakeholders must be

defined. Product Name, “identify the product that will

be built. Instruct participants to name it as follows:

imagine this product in a box, what name would be

written on it?” (Aguiar e Caroli, 2022, p. 52).

Problems, in this item, it is necessary to identify

and understand the current state of the product,

highlighting the problems and challenges. It is

ICSOFT 2025 - 20th International Conference on Software Technologies

290

interesting to instruct participants to collaborate in the

analysis of the current scenario. Expectations, this is

the stage where the desired state of the product is

identified, adjusting the expectations listed in relation

to the problems presented to understand the current

state. Ask participants to list the possibilities that help

solve the problems and pains of the current state.

2. Describe the personas: “A persona represents a

product user and this description should speak not

only of the role, but also of their needs and objectives.

This creates a realistic representation of the users,

helping the team to describe features from the point

of view of those who will use the product” (Aguiar e

Caroli, 2022, p. 55). In Canva, the persona is listed

with their activities.

3. Understand the features: “Feature is the

description of an action or interaction of a user with

the product. For example: requesting a shared

transport, consulting the detailed statement and

making an online purchase. The description of the

feature should be as simple as possible” (Aguiar e

Caroli, 2022, p. 57). In Canva PBB, each feature

should be described with a brief explanation,

highlighting the "Problems" it aims to solve and the

"Benefits" it provides.

4. Identify the PBIs: Caroli and Aguiar (2022)

state that PBIs (Product Backlog Items) are elements

of the Product Backlog that represent the

development work to improve the product, meeting

the needs of the customer or stakeholders. After

describing features, listing their problems and

benefits, you can identify the PBIs, dividing the

features into smaller and more precise items. Asking

what the first, second and next work items are can

help you write the PBIs.

The process that is responsible for identifying and

creating a PBI is called Step Maps. “In PBB, the

breakdown of features into PBIs is done by means the

Steps Map, a technique that helps to break down a

feature into small steps, and each of them will be a

PBI” (Aguiar e Caroli, 2022, p. 62). The Steps Map

is applied in two stages: Defining the step-by-step

process of the feature, at which point a work flow is

defined. If the feature was "Register Book", for

example, what would be the first step? Evolving each

step with questions, comments and ideas, complete

each step of the feature with questions, comments and

ideas. Reevaluate each one of them. A question can

eliminate an unnecessary step, just as a comment can

improve a useful step, and an idea can generate a new

step.

In the end, by following the sequence of steps of

the Canva PBB, the list of PBIs will be obtained, this

is the list with the items of the Product Backlog. Each

PBI describes a user action in the product. Caroli and

Aguiar (2022) explain that the actions are written in

textual way to provide context and uniquely identify

an item. The authors also suggest that PBIs be written

in the ARO model. “Development work to improve

the product by meeting the needs of the customer or

stakeholders” (Aguiar e Caroli, 2022, p.60). In the

ARO model, each PBI is described as an action, result,

and object.

The product backlog is an ordered and emerging

list of what is needed to improve the product

(Schwaber and Sutherland, 2020). Thus, an "ordered

and emerging" product backlog is a prioritized and

continuously updated list of product needs.

Every project requires prioritizing work items.

Agile teams, in particular, need to do this carefully,

as they perform incremental deliveries. The

prioritization of work items determines the order in

which they will be developed. COORG is the PBB

prioritization technique, responsible for prioritizing

PBIs (Aguiar and Caroli, 2022). It is an acronym for

classify, order, and organize. COORG helps the team

prioritize the backlog, with the aim of planning and

aligning the work flow and/or the next sprints.

COORG has a few steps: (i) Classify, the first step

of COORG is to classify each PBI, establishing

criteria and classification scales with the team,

according to the product context. According to the

authors, it is crucial to align and decide on these

criteria before classifying the PBIs, (ii) Order, the

second step of the COORG method is to order the

features in a logical sequence, like a narrative, also

moving their respective PBIs to be below them, and

(iii) Organize, is the last step of the COORG method,

organize the PBIs of each feature from top to bottom

by priority, after that place the PBIs with the highest

score in the first row, and so on, in descending order.

Aguiar and Caroli (2022) state that the result of

COORG activities should not be definitive. It is an

initial prioritization that can and should be updated as

the backlog evolves and new items emerge.

3 THE COMPLIANCE ANALYSIS

The analysis of the fulfillment of the Expected

Results of the MPS.BR Requirements Engineering

Process and the requirements construction stages of

the agile PBB method revealed significant insights. In

the following subsections, we present a summary of

the findings, highlighting whether the results were

fully met, partially met or not met at all.

The results are organized as follows: Expected

Result (acronym for the expected result of the

MPS.BR process defined in section 2.1), Description

of the Expected Result (detailing what is requested in

the expected result), PBB Corresponding Techniques

(PBB technique applicable to the MPS.BR expected

A Compliance Analysis of Agile PBB Method Practices with the Expected Results of the Requirements Engineering Process of the MPS.BR

Maturity Model

291

result) and Fulfillment Status (PBB's compliance

level to MPS.BR).

3.1 REQ1

Description of the Expected Result: in order for

REQ1 to be met, the needs, expectations and

restrictions of the stakeholders, both in relation to the

product and its interfaces, must be identified. The

customer's need is what solves the problem. It is from

the needs that the product's features arise. As for the

customer's expectations, they are related to the quality

of the product, the ideal scenario. The restrictions are

characteristics of the solution. For example, if the

customer's company only uses MacOS operating

systems, the application that will be developed must

run on that platform.

PBB Corresponding Techniques: the Product

Contextualization Stage, which includes the Name,

Problems, and Expectations sessions, helps the team

understand where they are in relation to the product

and where the customer wants to go. The Definition

of Personas, responsible for identifying the users of

the product, whose description should address not

only the role, but also list their needs and objectives.

Fulfillment Status: Partially Met, because the

REQ1 asks for the formal description of needs,

expectations, and constraints. However, in the PBB

Product Contextualization process, only expectations

are formally described, along with the needs from the

discovery of stakeholders in the Definition of

Personas stage. Since there is no corresponding

technique that identifies and lists the constraints of

stakeholders, REQ1 is partially met.

3.2 REQ2

Description of Expected Result: REQ2 asks that

product requirements be specified, prioritized,

refined, allocated for implementation, and kept up to

date based on the needs, expectations, and constraints

identified in REQ1. This includes specifying

operational concepts, scenarios, and internal and

external interfaces. Interface is the name given to the

way in which communication occurs between two

distinct parts of an application that cannot connect

directly. Operational concepts are related to the

prototyping of the requirement, which can be shown

by means a diagram, showing the steps of how the

requirement is operationalized. A scenario is a

sequence of events that can occur when using a

product.

PBB Corresponding Techniques: among the

techniques corresponding to REQ2 are Feature

Definition, Step Maps, COORG, PBI, and, finally, the

Product Backlog itself. In PBB, by means the

Personas needs, each action or interaction of them

with the system is described by a Feature. The feature

names the user action and needs to be detailed and

specified, as requested by REQ2. This process is

performed using the Step Map, which breaks down

the feature into smaller steps and sequentially maps

the user actions, generating the PBI (Product Backlog

Item). Finally, the set of PBIs constitutes the Product

Backlog. The Step Map, by sequentially mapping the

user actions to generate the PBI, also creates an

internal interface between these PBIs, which is

related to the operational concept of REQ2, as it

shows the operationalization of the requirement.

COORG (acronym for Classify, Order and ORGanize)

is a technique that helps the team prioritize the PBIs

of the Product Backlog for planning a Sprint.

Fulfillment Status: Partially Met, because PBB

does not cover the specification of scenarios and

external interfaces. In addition, the requirements are

not allocated during the techniques mentioned above,

nor are they kept up to date (versioned).

3.3 REQ3

Description of Expected Result: this is the

commitment of the technical team to implement the

requirements, which can be evidenced in many ways,

including meeting minutes, emails or other

appropriate documentation methods. PBB

Corresponding Techniques: Not applicable.

Fulfillment Status: Not Met, because the PBB does

not have a step in which the commitment of the

technical team is evidenced.

3.4 REQ4

Description of Expected Result: a system must be

established and maintained to track the relationship

between requirements and work products in a

software project. This means ensuring that each

requirement is linked to its corresponding work

product, such as documents, source code, and test

cases, and that the work products are linked back to

the requirements. It is about maintaining a clear

connection between what is needed and what is

produced in the software project.

PBB Corresponding Techniques: PBB has

vertical traceability in the process of creating Step

Maps from a Feature, that is, from the feature, steps

are identified that represent smaller units of a Feature.

Fulfillment Status: Partially met, because PBB

does not have a horizontal traceability mechanism,

which represents the dependency relationship

between the steps defined from the creation of a Step

Map. Although there is a vertical traceability

mechanism.

ICSOFT 2025 - 20th International Conference on Software Technologies

292

3.5 REQ5

Description of Expected Result: this means that it is

necessary to ensure that all project elements, such as

plans, activities, and work products, are aligned with

the defined requirements. Reviews, such as project

monitoring and control, must be performed. During

these reviews, inconsistencies must be recorded and

corrective actions must be taken to solve them.

Whenever there are changes in requirements, it is

necessary to examine whether the other project work

products are consistent with these changes. For

example, it is necessary to verify whether the project

estimates, scope, and schedule have been updated to

reflect the changes in requirements. The actions to

correct inconsistencies must be monitored until they

are completely solved, thus ensuring consistency

between the requirements and the project work

products.

PBB Corresponding Techniques: Not

applicable. Fulfillment Status: Not Met, because

PBB does not review everything that was generated,

consequently it does not identify inconsistencies and

does not address them.

3.6 REQ6

Description of Expected Result: requirements are

understood and analyzed to ensure that they are clear,

necessary, and sufficient; this guarantee must be

evidenced by means work products.

The analysis of software requirements is

performed in collaboration with stakeholders.

Requirements must be balanced against existing

needs and constraints. For this reason, they must be

clear.

PBB Corresponding Techniques: the process of

building the Product Backlog in PBB is collaborative;

stakeholders and customer needs are defined by the

Description of Personas. The following techniques in

the process, such as Feature Definition, Step Maps,

COORG, and PBI, build the Product Backlog, which

is the list of requirements that will be analyzed.

Although these steps refine the requirement, they do

not formally guarantee that the requirement is clear,

necessary, and sufficient.

Fulfillment Status: Partially Met, because the

process steps do not guarantee that the requirements

are clear, necessary, and sufficient. There is also no

balancing or versioning mechanism in the PBB

method.

3.7 REQ7

Description of Expected Result: validation is a

process that evaluates whether the requirements are in

accordance with the customer's needs. The objective

of this result is to ensure that the project team and the

requirements providers have a common

understanding of the requirements. This expected

result requires a more specific and descriptive

validation method, such as Use Case Analysis,

Prototyping, INVEST (Independent, Negotiable,

Valuable, Estimable, Small and Testable) criteria,

among others.

PBB Corresponding Techniques: Not

applicable. Fulfillment Status: Not Met, because

PBB does not have a validation step.

4 COMPLIANCE ANALYSIS

EVALUATION

As described in (Elsevier, 2023), peer review is an

evaluation process in which an author's work, such as

a scientific paper/article, is examined by experts in

the same field before being published. This process

ensures the quality, accuracy, and relevance of the

research, helping to identify errors, suggest

improvements, and validate the results presented. It is

a common practice in scientific journals and

academic conferences to ensure that only high-quality

work is accepted for publication.

To evaluate the results obtained in this study, a

peer review was carried out with two experts, with the

objective of validating the adherence of Product

Backlog Building (PBB) to the Expected Results of

the MPS.BR Requirements Engineering Process.

Expert1 has a degree in Data Processing

Technology, a specialist in Systems Analysis, a

Master's degree, a PhD, and a Post-Doctorate in

Computer Science. He is currently an Associate

Professor at a Federal University in Brazil and

coordinates the a research project, which which

conducts research on the development of solutions to

support the software process improvement. He also

works as a Consultant-Implementer, Evaluator and

Instructor of the MPS.BR and CMMI quality models.

Expert2 is an Executive Consultant at Accenture,

with over two decades of experience in software

development. In recent years, he has focused on

product management practices, specializing in

complex product management in fast-growing global

companies. He holds a Bachelor's degree in

Information Systems, technical training in Systems

Development, and is a Specialist in Software Process

Engineering. Expert2 is the author of the book

"Product Backlog Building (PBB) - A practical guide

for creating and refining backlogs for successful

products", and creator of the PBB method.

A review was initially conducted with the

MPS.BR expert (Expert1) to validate the correct

A Compliance Analysis of Agile PBB Method Practices with the Expected Results of the Requirements Engineering Process of the MPS.BR

Maturity Model

293

interpretation of the Expected Results in the MPS.BR

Requirements Engineering Process. After

implementing the recommended adjustments, a

second review was conducted to evaluate the PBB's

compliance analysis with the Expected Results of the

MPS.BR Requirements Engineering Process. Finally,

a third review was carried out, this time with the

participation of both experts, to jointly evaluate the

compliance analysis.

4.1 Corrections Applied in the First

Peer Review

Regarding the interpretation of the Expected Results

of the MPS.BR Requirements Engineering Process,

the following correction points were identified below.

In REQ 6, Problems pointed out by the expert:

the text did not identify the obligation to present

evidence proving that the requirements are necessary

and sufficient. Solution: make adjustments to the text

to make it clear that evidence proving that the

requirements must be necessary and sufficient must

be presented.

In REQ7, Problems pointed out by the expert:

the text did not identify that the validation is thorough.

Solution: make adjustments to the text emphasizing

that this expected result requires a more thorough

validation method, such as Use Case Analysis,

Prototyping, INVEST criteria, among others.

The adjustments made in the first peer review

aimed to emphasize details that require attention

when organizing the evidence at the time of

implementation.

4.2 Corrections Applied in the Second

Peer Review

Regarding the analysis of PBB compliance with the

Expected Results of the MPS.BR Requirements

Engineering Process, the following correction points

were identified below.

In REQ 1, Problems pointed out by the expert:

REQ1 is not fully met because it does not cover the

description of the Product's Needs and Constraints.

Add the Persona Definition step, as it identifies the

stakeholders. Solution: the fulfillment status was

changed from "fully met" to "partially met". Persona

Definition was added as a technique corresponding to

REQ1, as suggested by the expert, since it was found

that the customer's needs are listed together with the

persona. Therefore, it was concluded that only the

constraints are not met in the REQ1.

Initially, REQ1 had the fulfillment status of "fully

met", as it is a requirement in which initial contact

with the customer and the identification of their needs

occurs. Due to the fact that the contextualization stage

has a similar process, it was believed that this stage

would be sufficient to meet REQ 1. However, REQ 1

makes it clear that the needs, expectations, and

constraints must be described, as pointed out by the

expert.

In REQ 2, Problems pointed out by the expert:

the Persona Description technique is associated with

REQ 1. The PBB does not keep the requirements

updated and does not have a Canvas versioning

mechanism. Add that the Step Maps process covers

the operational concept and the operationalization of

the requirements, but does not cover the scenarios of

REQ 2. Solution: the Persona Description was

allocated to REQ 1 and removed from REQ 2, as

requested. It was inserted in the text explaining the

status that the PBB does not have a versioning

mechanism for the Canvas produced and that the Step

Maps cover the operational concept of REQ 2.

However, the scenarios continue not to be met.

In REQ2, adjustments were needed to the persona

description due to the change in REQ1. Initially, it

was believed that the PBB kept the requirements up

to date. Although the backlog evolves and new items

are added, this does not guarantee that the

requirements "remain up to date", since the method

does not mention any versioning mechanism to

highlight the changes that occur in the PBB Canvas.

Another item pointed out by the expert, which had

not been mentioned previously, is that the Step Maps

encompass the operational concept, that is, the

operationalization of the requirements, which

consists of converting an abstract need or objective

into specific actions and tasks that can be executed in

the system development or operation. The Step Maps

define the step-by-step functionality.

In REQ 6, Problems pointed out by the expert:

add that the PBB method does not show whether the

requirements are clear, necessary and sufficient.

There is no adequate documentation. Solution: the

suggested correction was inserted in the status

explanation text, emphasizing that there is no

adequate documentation or step to demonstrate

whether the requirements are clear, necessary and

sufficient.

Although in PBB the requirements are implicitly

clear, necessary and sufficient, there is no work

product, document or step that demonstrates this.

4.3 Corrections Applied in the Third

Peer Review

The third peer review also focused on the analysis of

the PBB's compliance with the Expected Results of

the MPS.BR Requirements Engineering Process.

This review was attended by two experts, where the

mapping and compliance analysis were presented to

ICSOFT 2025 - 20th International Conference on Software Technologies

294

the PBB expert so that he could point out his

considerations. In this review, a peer review was

adopted with the criteria described below: (i) High

technical (HT) - indicating that a problem was found

in an item that, if not changed, compromises the

considerations, (ii) Low technical (LT) - indicating

that a problem was found in an item that would be

convenient to change, (iii) Editorial - indicating that

a grammatical error was found or that the text needs

to be improved, (iv) Questioning (Q) - indicating that

there was doubt regarding the content of the

considerations, (v) General (G) - indicating that the

comment is general in relation to the considerations.

The following considerations were raised:

Request - No vertical traceability was detected in the

PBB, Type - HT, Correction Proposal -

Bidirectional traceability between requirements,

activities and project work products is established and

maintained. The PBB has vertical traceability in the

process of creating Step Maps from a feature, that is,

from the functionality, steps that represent smaller

units of a feature are identified, Status - Done.

This issue was identified in REQ 4, which

bidirectional traceability between requirements,

activities and project work products is established and

maintained. All items requested by the experts were

considered for adjustments and the content presented

in Section 4 includes all the adjustments requested by

the experts.

5 CONCLUSION

The analysis conducted in this study demonstrates

that, although the adoption of agile methods, such as

PBB, has the potential to improve requirements

engineering in software development, there are

significant limitations when these practices are

compared to the rigorous criteria established by

MPS.BR model. The growth of the Brazilian software

market and the need to quickly adapt to technological

changes highlight the importance of methodologies

that not only speed up development, but also ensure

quality and compliance with reference models, such

as MPS.BR.

The results of the compliance analysis showed

that, of the seven Expected Results of MPS.BR, four

were partially met by PBB. This is due to the fact that

PBB is a method focused on requirements

development, while the MPS.BR Requirements

Engineering process involves both requirements

development and management.

This research provides a detailed and updated

analysis based on the MPS.BR General Software

Guide in its 2024 version, which, unlike previous

versions, addresses requirements development and

management in the same process. PBB, recognized as

an innovative method in Requirements Engineering,

not only represents a technical advance, but also

reflects the potential for Brazilian innovation.

Therefore, it is gratifying to contribute to the software

development community and have an analysis

evaluated by the creator of the method.

Among the limitations of this research, it is worth

highlighting that only a compliance analysis was

performed, without investigating how to solve the

gaps and non-compliance with the expected results.

In addition, the research, although validated by means

a peer review, was not tested in a real corporate

environment.

For future research, it is suggested to focus on

how to solve the gaps and non-compliance found by

means the adaptations to the PBB, to fully meet the

MPS.BR expected results.

REFERENCES

Aguiar, F., Caroli, P. (2022). Product Backlog Building: A

practical guide to define, prioritize and refine backlogs

for successful products. 1st edition. Caroli Publishing.

Cunha, J. Y. C., Oliveira, S. R. B. (2022). Analysis of PBB

Compatibility with the Expected Results of the

MPS.BR Requirements Development Process. In: 19th

International Conf. in Information Systems and

Technology Management (CONTECSI), Brazil.

Elsevier (2023). What is peer review? Available in: https://

www.elsevier.com/pt-br/reviewer/what-is-peer-review.

Accessed: February 26, 2025.

Larman, C. (2004). Agile and iterative development: a

manager's guide. Boston: Addison-Wesley Professional.

Schwaber, K., Sutherland, J. (2020). The Scrum Guide - The

Definitive Guide to Scrum: The Rules of the Game.

Available in: https://scrumguides.org/docs/scrumguide/v

2020/2020-Scrum-Guide-US.pdf. Accessed: February

26, 2025.

Silva, B. W. F. V. da, Oliveira, S. R. B. (2020). REACT-M:

A Case Study Report on the Application of an Agile

Method for Software Requirements Management. In:

20th Workshop em Engenharia de Requisitos, Brazil.

SOFTEX (2024). MPS Software General Guide: 2024.

Available in: https://softex.br/download/guia-geral-

mps-de-software2024. Accessed: February 26, 2025.

Sommerville, I. (2015). Software Engineering. 10th edition.

Pearson.

A Compliance Analysis of Agile PBB Method Practices with the Expected Results of the Requirements Engineering Process of the MPS.BR

Maturity Model

295