Integrating Systems Thinking into Software Engineering Education: A

Teaching Experience

Rodrigo Correa

1 a

, M

arcia Lima

2 b

and Tayana Conte

1 c

Instituto de Computac¸

ao, Universidade Federal do Amazonas, Manaus, Brazil

Universidade do Estado do Amazonas, Manaus, Brazil

Keywords:

Systems Thinking, Critical Systems Heuristics, CSH, Software Engineering Education.

Abstract:

Context: The rapid evolution of software engineering in response to the complex demands of the modern dig-

ital society has led to increased pressure on developers to adapt quickly. However, a pragmatic approach often

overlooks the deeper theoretical foundations, which can result in inefﬁcient software development practices.

Systems Thinking (ST), particularly through Critical Systems Heuristics (CSH), offers a reﬂective and holistic

approach to address these challenges, especially in the software requirements elicitation phase. Goal: This

research aims to relate an experience of introducing Systems Thinking to undergraduate students using Critical

Systems Heuristics as a support tool in a requirement elicitation process. Method: A mixed-methods educa-

tional experience was conducted with 36 undergraduate software engineering students. The students applied

the CSH framework during an assignment on software requirements elicitation. The effectiveness of CSH was

assessed through both quantitative measures (number and categorization of elicited requirements) and quali-

tative feedback (students’ perceptions and reﬂections). At the end of the project, we collected the students’

reﬂections about the application experience to gather students’ feedback Results: The application of CSH led

to the elicitation of 372 total requirements, of which 25 were derived using the CSH framework. Students

reported a positive impact on their overall understanding of the system but also highlighted challenges related

to the complexity and time-consuming nature of the framework. Conclusion: The study demonstrates that

the CSH framework can be a valuable tool in software requirements elicitation, aiding in the understanding

the problem’s context and in the conﬁrmation of requirements. While students acknowledged its beneﬁts, they

also recognized its limitations, suggesting that further reﬁnement is needed for practical use. This experience

contributes to the integration of Systems Thinking in software engineering education and offers insights into

its potential and challenges.

1 INTRODUCTION

The complexity of our world has grown signiﬁcantly,

leading to an increased reliance on computers to help

us understand it, in light of this, software and services

are the backbone of modern society, deeply embedded

in every aspect of our life (Moreira et al., 2024).

Characteristics and demands of the modern and

digital society have transformed the software develop-

ment scenario and presented new challenges to soft-

ware engineers, such as faster deliveries, frequent

changes in requirements, lower tolerance to failures,

and the need to adapt to contemporary business mod-

els (Barcellos, 2020). However, the urgent need for

https://orcid.org/0009-0009-2217-4136

https://orcid.org/0000-0002-4913-7513

https://orcid.org/0000-0001-6436-3773

solutions increases pressure on software development

organizations that adapt and combine software devel-

opment practices and processes in a purely pragmatic

fashion without any critical considerations, creating

a tendency that ”the truth is what works” (Donaires,

2006). This approach detaches practices and pro-

cesses from the methodological context in which they

were proposed, and are rearranged based on partial

knowledge with no theoretical or conceptual depth,

consequently, the software development process that

emerges from this trial-and-error learning process un-

avoidably incorporates many bad habits (Donaires,

2006). Coping with these challenges is complex and

involves various aspects, such as processes, people,

tools, policies, and culture, which require a broad

and systemic view of the organizational environment;

System Thinking has been identiﬁed as a suitable ap-

Correa, R., Lima, M. and Conte, T.

Integrating Systems Thinking into Software Engineering Education: A Teaching Experience.

DOI: 10.5220/0013366300003932

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 17th International Conference on Computer Supported Education (CSEDU 2025) - Volume 1, pages 547-554

ISBN: 978-989-758-746-7; ISSN: 2184-5026

547

proach to provide such a view Borges et al. (2024).

Systems Thinking (ST) advocates for understand-

ing complex phenomena by examining them as inter-

connected wholes rather than as isolated parts (Mag-

nus Ramage, 2020). Traditionally, problem analysis

involves breaking down an issue into smaller, man-

ageable pieces, focusing on each part individually

before attempting to reconstruct a holistic view, as

outlined by Borges et al. (2024). As illustrated in

Moreira et al. (2024), Systems Thinking can be ap-

plied through various approaches, such as Soft Sys-

tems Methodology, Critical Systems Heuristics, and.

There are also various Systems Thinking Modeling

Tools, such as Causal Loop Diagrams, Inﬂuence Di-

agrams, Feedback Loops, and Simulators (Borges

et al., 2024). Critical Systems Heuristics (CSH) pro-

vides a reﬂective framework based on practical phi-

losophy and Systems Thinking, structured around

twelve guiding questions that support system design-

ers in critically assessing the properties and relation-

ships within a system, as proposed in Ulrich (2005).

In the context of software engineering, a study

conducted in Donaires (2006) argues that a criti-

cal approach is essential for guiding decision-making

throughout the software development process, rather

than using the current pragmatistic view. For this, the

author adopted a systematic framework, named Crit-

ical Systems Heuristics (CSH), to navigate complex

choices effectively and achieve a systemic view. Ac-

cording to Donaires (2006), this approach is partic-

ularly important in software development, as it must

reconcile diverse components, such as stakeholder in-

terests, ensure that the software meets its speciﬁed re-

quirements, and evaluate customer satisfaction.

One of these components, the software require-

ments, are obtained from the requirement elicitation

process, which is recognized as a fundamental set

for the success of software projects since incorrect

practices can lead to project failure (Mendonc¸a et al.,

2021). This phase is dedicated to identifying and un-

derstanding the user’s needs, which in turn generate

software requirements that serve as the foundation

for development, testing, and maintenance activities

(Daun et al., 2022).

Considering that the requirement engineering

phase is important to the software development pro-

cess and fundamental for the curriculum of new Soft-

ware Engineers, our attempt to integrate ST in SE

teaching will focus on this area, since it is the mo-

ment when the stakeholder’s needs and conﬂicts must

be aligned for the proper software development. Our

hope is that students will be able to address the sys-

tematic complexity related to the software develop-

ment process using Systems Thinking, reﬂecting crit-

ically on the stakeholders and environmental variables

involved. In this sense, we proposed Critical Systems

Heuristics as a way to apply this critical thinking.

Aligned with the perspectives exposed in Donaires

(2006) and Barcellos (2020), aiming to support the

teaching-learning process in SE and to contribute to

the ST research in the area, this study presents an edu-

cational experience that integrates the use of Systems

Thinking (ST) and Critical Systems Heuristics (CSH)

into software engineering (SE) teaching.

The experience involved 36 undergraduate Soft-

ware Engineering students who participated in a train-

ing phase and an assignment on the requirement elici-

tation process, where they also recorded their percep-

tions of the CSH framework. Students applied CSH

as a supporting tool during the software requirements

elicitation phase to assess if this Systems Thinking

(ST) approach would improve their understanding of

software system domains and strengthen the elicita-

tion process. A mixed-methods analysis evaluated the

framework’s effectiveness, combining both quantita-

tive and qualitative approaches. Quantitative results

showed that 372 total requirements were elicited, in-

cluding 302 functional and 72 nonfunctional require-

ments, with 25 requirements (14 functional, 11 non-

functional) elicited using the CSH framework, ac-

counting for only 6.3% of the total. The qualitative

analysis revealed a mixed perception of CSH: partic-

ipants reported increased understanding of the prob-

lem but noted challenges, such as the framework be-

ing complex, time-consuming, and yielding a limited

number of requirements. Positive, negative, and re-

ﬂective feedback was gathered from students regard-

ing their experience using the CSH framework.

Those results show that the CSH framework can

be used as a support tool in the software requirement

elicitation phase since it can help the elicitation of

new software requirements and conﬁrm some already

elicited requirements. Furthermore, the students re-

ﬂected critically on the CSH framework about its po-

tential and limitations.

2 BACKGROUND

Systems Thinking (ST): is an approach designed to

address complex, uncertain real-world problems by

focusing on the interrelationships and dependencies

between entities rather than just the entities them-

selves (Cabrera et al., 2008). The authors also stand

that this perspective helps frame problems compre-

hensively, ensuring critical interconnections are not

overlooked while managing uncertainties and iden-

tifying opportunities. ST’s multidisciplinary nature

CSEDU 2025 - 17th International Conference on Computer Supported Education

548

spans ﬁelds like business, education, and health, and it

conceptualizes an organization as a system composed

of elements such as teams, artifacts, and policies, as

well as their interconnections, like the relationship

between a development team, software artifacts, and

production policies (Borges et al., 2024). These com-

ponents are structured to produce behaviors that de-

ﬁne the organization’s function or purpose.

In the sense of this paper, Systems Thinking was

already used in many areas within SE, such as Re-

quirements Engineering, covered in Williams and

Kennedy (1999) discusses the use of ST as a problem-

solving technique in Requirements Engineering to

help understand the Requirements Engineering pro-

cess effectiveness and evolution over time. In a study

conducted by Andersson et al. (2002) the authors use

ST Modeling Tools to analyze variables involved in

software development processes. Software Testing,

as shown in Huang and Fang (2022), when ST was

used to model software testing situations, aims to in-

crease software quality by helping developers to make

decisions considering the pressure of software release

schedule and the constraints of testing costs.

Especially about Software Engineering Educa-

tion, Moreira et al. (2024) stands for integrating this

way of thinking to foster a more just and sustainable

future in computing. The study conducted in Boehm

and Mobasser (2015) promotes that ST can be used

to form T-shaped software engineers, that is, a pro-

fessional with not only deep technical skills but also

working knowledge of other curriculum disciplines.

Similarly, ST was integrated into a new course in the

computing undergraduate curriculum at a university

in Oxford, aiming to understand failures in IT sys-

tems by analyzing the relations between stakeholders

(Wermelinger et al., 2015).

Critical Systems Heuristics (CSH): framework, de-

veloped by Werner Ulrich, provides a structured ap-

proach to reﬂective practice by combining princi-

ples from practical philosophy and Systems Think-

ing. CSH encourages a critical stance by guiding

practitioners through a systematic examination of the

boundaries that shape their judgments and decisions

within complex systems (Ulrich, 2005). It is particu-

larly suited for situations where diverse interests, val-

ues, and perspectives must be reconciled, making it

valuable in ﬁelds such as software engineering.

The CSH framework is anchored in three founda-

tional concepts:

1. Critical. CSH promotes a reﬂective mindset, ad-

vocating for continuous questioning and examination

of assumptions that underlie decisions. It recognizes

that there is no single ”right” solution, as judgments

are often shaped by subjective values, individual per-

spectives, and varying objectives.

2. Systems. Following the principles of Systems

Thinking, CSH views each problem or system as in-

terconnected with its broader environment. This ap-

proach emphasizes understanding the system as a co-

hesive whole, where problem deﬁnitions, proposed

solutions, and evaluations are intrinsically linked.

3. Heuristics. Heuristics in CSH involve an ex-

ploratory process of identifying relevant questions,

assumptions, and solution strategies, supporting ﬂex-

ible thinking and encouraging practitioners to con-

sider qualitative aspects like the implications and lim-

itations of different boundary judgments. The core

concept of the CSH framework is Boundary Critique,

which involves critically assessing boundary judg-

ments—assumptions that determine what is included

or excluded in the system analysis. By examining

these boundaries, CSH seeks to uncover the selec-

tivity in problem framing and solutions, promoting a

more inclusive and transparent decision-making pro-

cess. Boundary Critique can be used in reﬂective

practice, where practitioners assess their own bound-

ary judgments, or in emancipatory practice, which

challenges imposed boundary judgments to ensure

fairness and representation for all stakeholders.

To implement the boundary critique, CSH orga-

nizes its analysis around twelve boundary questions,

categorized into four main sources of inﬂuence that

shape any system’s design and function:

(1) Motivation. Questions related to purpose and

beneﬁciaries, such as ”Who is (ought to be) the client

or beneﬁciary?” (2) Control. Questions about author-

ity and resource management, like ”Who is (ought

to be) in control of the conditions of success?” (3)

Knowledge. Questions about expertise and knowl-

edge sources, including ”Who is (ought to be) con-

sidered a competent provider of experience and ex-

pertise?” (4) Legitimacy. Questions about represen-

tation and fairness, such as ”Who represents (ought

to represent) those affected by, but not directly in-

volved in, the system?” Each question is posed in

two ways—what is the case and what ought to be

the case—prompting practitioners to evaluate both

the current state and ideal scenarios. By addressing

these questions, CSH allows system designers and

decision-makers to critically assess whose interests

are prioritized, what assumptions are guiding their

choices, and how the system could better serve a di-

verse range of stakeholders.

In the context of this study, CSH was used as

a framework for supporting students in the require-

ments elicitation phase of software engineering. By

applying the boundary questions, students were able

to examine not only the functional and nonfunctional

Integrating Systems Thinking into Software Engineering Education: A Teaching Experience

549

requirements of their software systems but also the

broader social, ethical, and operational implications.

This approach aimed to develop students’ ability to

critically analyze the requirements and limitations of

their designs, fostering a more holistic and ethically

informed perspective on software development.

2.1 Related Work

Since CSH has a multidisciplinary characteristic, var-

ious studies were conducted utilizing it throughout

different areas, for example, in Nayeri et al. (2020) the

authors used the CSH framework to address problems

in the Iranian Bank System, caused by the increase of

Non-performing loans. The use of the CSH frame-

work aided in understanding that the Central Bank

had less authority than it should and that the Central

Bank suffered from the lack of modern banking at the

corporate level.

A study conducted by Manduna et al. (2022) about

teaching programming using Instant Messaging chose

CSH as a way to deal with the student’s different so-

cial and economic realities. After the use of the CSH,

their teaching guidelines were updated.

In light of the industry scenario, Donaires (2006)

applied this framework to elucidate how the inter-

relations affect the software development process, due

to the uncertainty of its variables. It also states that the

framework can be used to audit the software process,

suggesting changes and evaluating the process.

Requirement Engineering (RE) also beneﬁts from

the CSH usage, as shown in Duboc et al. (2020), to

develop a software aimed at helping elderly people

living at home by detecting unusual sounds that might

indicate possible changes in routine or accidents, the

CSH framework role was to provide an effective fram-

ing for developing a reﬂexive understanding of stake-

holders , as a result, the authors learned that if not

carefully designed, the system could reduce the au-

tonomy of the elderly.

As observed, Critical Systems Heuristics have

been applied in different areas with different objec-

tives. Therefore, this work aims to use the CSH

framework as a support tool for the requirement elic-

itation process.

3 METHODOLOGY

We conducted a study to evaluate the integration of

Systems Thinking and Critical Systems Heuristics in

SE teaching using the CSH framework as a support

tool for the requirement elicitation process. The study

was conducted with 36 students in a software engi-

neering course. The course objective was to teach

students the main topics of SE, such as SE princi-

ples, Software lifecycles, Agile Methodology, Re-

quirement Engineering, and Software Testing. The

overall methodology process is shown in Figure 1.

3.1 Training Phase

In this subsection, we present our approach regarding

the ST and CSH teaching to the participants. The pro-

cedure is divided into 5 steps, as shown in the green

group of Figure 1.

Lecture About ST and CSH. This step aimed to in-

troduce the participants to the theoretical foundations

of Systems Thinking and Critical Systems Heuristics,

which were necessary for the upcoming exercise and

assignment. This step was conducted in 1 hour. The

materials used in this step are available in the com-

plementary material

. Access to these materials was

available to the participants at any time to ensure they

had access to any information needed during the next

practices.

Training Exercise on the CSH Framework. Af-

ter the lecture, participants worked in groups of 5 to

6 members to apply the CSH framework to a train-

ing system and had to identify requirements based on

their answers to the framework’s questions. They also

classiﬁed the requirements as functional or nonfunc-

tional. The training system is included in the data

replication package. Participants had 1 hour to com-

plete the exercise, detailed in the next 2 steps.

Answer the CSH Framework. The participants had

to answer the CSH framework’s questions according

to the context given. Since the participants had only

1 hour for the exercise, they were allowed to answer

only 2 questions about each Source of Inﬂuence.

Elicit Requirements from the Framework’s An-

swers. The participants had to elicit software require-

ments based on their answers, classifying them into

functional or nonfunctional requirements. As a re-

sult, at the end of the exercise, each group generated a

list of functional and nonfunctional requirements. We

collected the resulting list together with the group’s

CSH framework answers.

Analyze the Framework’s Answers and Elicited

Requirements. The researchers analyzed the partic-

ipants’ responses and elicited requirements to assess

their understanding of the CSH framework and their

ability to apply it in a practical task. This step took

three days to accomplish.

https://ﬁgshare.com/s/ecbcb6a4f33acd4cd7ea

CSEDU 2025 - 17th International Conference on Computer Supported Education

550

3.2 Execution Phase

In this subsection, we present the steps taken for the

execution of the assignment. All the steps involved

in this phase are highlighted by the yellow color in

Figure 1 and are described as follows:

Proposal of an Assignment on the Requirements

Elicitation Process. On the second day, participants

received an assignment from the professor, detailed in

the ’Requirement Elicitation Assignment Speciﬁca-

tion’ document, available in the complementary mate-

rial. The goal was to apply different requirement elici-

tation techniques and the CSH framework, which was

of mandatory use, in a a real-world problem. Partic-

ipants were required to use at least three techniques,

such as interviews, questionnaires, personas, and em-

pathy maps. They formed groups of 3 to 5 members

and chose a real-world problem to address.

For example, Group 1 addressed research oppor-

tunities problem. In total, the participants formed 8

groups, 4 groups were composed of 5 participants,

and 4 groups were composed of 4 participants.

As a result, the groups created a technical re-

port containing the elicitation of requirements for

the systems they proposed, including the following

items (document: Requirement Elicitation Assign-

ment Speciﬁcation), available in the complementary

material

Item 1. Initial scope of the proposed system;

Item 2. Description of the demand or motivation for

creating the system;

Item 3. A list of elicited functional requirements for

the system

Item 4. A list of elicited nonfunctional requirements

for the system

Item 5. A list of identiﬁed business rules

Item 6. A list of priority requirements, which should

be delivered in a Minimum Viable Product (MVP) of

the system

Item 7. The answers of the CSH framework

Item 8. Requirements Tracking Table, in which the

participants had to register what techniques gener-

ated each of the elicited requirements and the related

Source of Inﬂuence

Item 9. Participant’s perception of the requirement

elicitation process, elicitation techniques, and the

CSH framework. This section was mandatory for the

assignments but did not impact the students’ grades.

Execute the Proposed Assignment The participants

had 23 days to execute the assignment. After the

deadline, the course professor reserved three classes

of two hours each for the presentation of the groups

https://ﬁgshare.com/s/ecbcb6a4f33acd4cd7ea

results. Each presentation had a time limit of 20 min-

utes followed by a brief debate about their results with

the other groups and the course professor.

3.3 Evaluation Phase

In this subsection, we present how was executed the

Evaluation Phase, highlighted by the blue color in

Figure 1. The Evaluation Phase is composed of two

steps, described in the following paragraphs.

Analyze the Framework’s Answers and Elicited

Requirements. This analysis contemplates the arti-

facts described in Item 7 and Item 8. We used the

data collected in Item 8 in quantitative analysis (see

Subsection 4.1) focusing on the proportion of elicited

requirements generated by the CSH framework and

the other techniques, along with the frequency of the

elicited requirements by each Source of Inﬂuence.

Analyze Student’s perceptions about the CSH

Framework. This analysis focused on the content

represented by Item 9 which are the participant’s per-

ceptions of the assignment. For this, we performed an

open coding based on their perceptions.

4 RESULTS

4.1 Quantitative

The quantitative analysis focused on the number of

requirements elicited and their categorization accord-

ing to the Sources of Inﬂuence. This analysis showed

that the groups elicited a total of 374 requirements, of

which 302 were functional requirements, and 72 were

nonfunctional requirements. Of the 374 requirements

elicited, 25 requirements were elicited using the CSH

framework, of which 14 were functional requirements

and 11 were nonfunctional requirements. We can ob-

serve that the CSH framework was responsible for a

small percentage (6.3%) of the elicited requirements

in comparison to other techniques (93.7%). This rela-

tively small percentage was expected, given the num-

ber of other techniques employed during the elicita-

tion process. Additionally, the CSH framework is not

intended to generate a large number of requirements,

but rather to produce differentiated requirements that

emphasize Systems Thinking perspectives.

Although there are more functional requirements

than nonfunctional ones in absolute numbers (14

functional requirements compared to 11 nonfunc-

tional requirements), we observe that nonfunctional

requirements stand out proportionally. This differ-

ence is attributed to the participants’ perception of the

Integrating Systems Thinking into Software Engineering Education: A Teaching Experience

551

Figure 1: Methodological Steps.

CSH framework’s ease of use in extracting nonfunc-

tional requirements, as presented in Section 4.2.

The Source of Control received most of the re-

quirements classiﬁcation (11 out of 25 elicited re-

quirements), demonstrating the participant’s concerns

about what success conditions were within their con-

trol and what environmental variables could affect

their product. In contrast, the Source of Legitimacy

accounted for the fewest classiﬁed requirements (1

out of 25 elicited), indicating that participants rarely

linked their requirements to how the proposed soft-

ware should allow users to express their opinions

about it. We also observed that some groups did not

classify the elicited requirements based on a Source of

Inﬂuence. This could be due to various factors, such

as participants forgetting to perform the classiﬁcation

or not understanding how to classify the elicited re-

quirements.

4.2 Qualitative

The data used in this subsection was collected by Item

9 of the assignment (Section 3.2). We organized the

participant’s perceptions into three categories, explor-

ing their positive, negative, and reﬂective perspectives

about using the CSH framework as a support tool in

the requirements elicitation process.

Positive. According to the participants’ perspective,

the positive aspects of the CSH framework on their

requirement elicitation assignment are:

Improvements in understanding the problem to

be solved. The participants described that the CSH

framework aided them in understanding relevant as-

pects of the problems they intended to solve, as noted

by P11: ”Regarding CSH, reﬂecting on issues beyond

the user was important. Security issues, for whom the

system is intended, and at what level the system will

reach that we, as designers, will be satisﬁed.”

Conciliation of stakeholders and user needs. The

participants reported that the CSH framework helped

them to observe that the users and the stakeholder

needs should be conciliated, as shared by P13: “it em-

phasized the need to develop a transparent and ethi-

cal system that meets the needs and expectations of

stakeholders in a fair and responsible manner.”.

The effectiveness in evaluating the importance of

the elicited requirements for their solution, as seen

by P35: “When we answered the CSH questions, we

were able to have a clearer direction regarding the

requirements we were proposing for our system.”.

Negative. In contrast, participants also expressed dif-

ﬁculties using the CSH framework:

Difﬁculty in understanding the framework’s ques-

tions. Participants reported that the framework’s

questions were challenging to interpret, leading to

negative perceptions, as reﬂected in P3’s statement:

“We had a lot of difﬁculties, the questions were not

very clear.”

Low perceived efﬁciency of the CSH framework

in the requirement elicitation process. Participants

stated that the framework supported the elicitation of

few requirements and was difﬁcult to use, perceiving

the CSH framework as an ineffective tool for the re-

quirement elicitation process, as highlighted by P4:

“The framework was the hardest to apply. It wasn’t

effective because it was complex, slow, and generated

few requirements.”

Some participants expressed a lack of conﬁdence

in using the CSH framework to elicit requirements,

as shared by P30: “I did not feel conﬁdent using this

framework.”.

Reﬂective. This category includes participants’ state-

ments offering critical reﬂections on their experiences

using the CSH framework in the assignment. The

comments are not strictly positive or negative; in-

stead, they focus on the participants’ usage of the

framework. The following participants shared these

insights:

Regarding the moment when the CSH framework

was used, the participants highlighted that the frame-

work would bring better results if it were employed

before any other requirement elicitation technique, as

observed by P5: “If it were one of the ﬁrst tech-

niques to be applied before deﬁning the scope post-

CSEDU 2025 - 17th International Conference on Computer Supported Education

552

elicitation, it could bring more results.”

Regarding the use of the CSH framework in com-

bination with other elicitation techniques, the partici-

pants reported that the requirements elicited using the

CSH framework could be elicited using other elicita-

tion techniques, as expressed by P3: “It just veriﬁed

that we would reach the same conclusion”

Regarding the conﬁrmation of the already elicited

requirements, the participants shared that the CSH

framework helped them to conﬁrm already elicited re-

quirements as said by P35: “It was of great impor-

tance for the ’reﬁnement’ process”

The CSH framework is more useful to elicit non-

functional requirements, as stated by P28: “The CSH

Framework added more value concerning nonfunc-

tional requirements.”.

5 LESSONS LEARNED

Regarding the Methodological Approach. Despite

eliciting requirements using the CSH framework, par-

ticipants faced difﬁculties, including issues under-

standing the framework’s questions, lack of conﬁ-

dence, and perceiving it as ineffective for the assign-

ment. Since the CSH framework was introduced in

an introductory SE course to students with no prior

knowledge of requirements elicitation, more training

is needed. The students received only one lecture

and two exercises, so additional lectures and exer-

cises may be necessary for better preparation. Fu-

ture research could explore other frameworks or tech-

niques that might yield better results, such as those

discussed by Borges et al. (2024), who examines var-

ious Systems Thinking Modelling Tools for Software

Engineering, or the use of Soft Systems Methodology

in requirements engineering, as noted by Niu et al.

(2011).

Regarding the CSH Framework. Some students

found the framework challenging to apply, with com-

plaints about the questions, since some students ex-

pressed that the questions were broad and could pro-

voke uncertainty. They found the questions difﬁcult

to understand, which led to a common feeling of in-

security. As a result, they felt unable to identify

the requirements using the framework. The partici-

pants also reported challenges with the extension of

the framework. Because the framework consisted of

a questionnaire with twelve open-ended questions, it

took a considerable amount of time to complete. The

large number of questions made the task more dif-

ﬁcult, requiring greater mental effort. Furthermore,

since the framework was part of a larger project,

students who invested signiﬁcant time into it with-

out seeing immediate results or impacts became frus-

trated with its use.

6 CONCLUSIONS

This study explores the use of the CSH framework for

requirements elicitation, aiming to introduce a Sys-

tems Thinking approach to software engineering edu-

cation as an alternative to traditional methods. Stu-

dents applied the CSH framework and other tech-

niques to elicit requirements for a group-identiﬁed

problem, documenting their process and perceptions

of the techniques used. The analysis of both the

elicited requirements and students’ reports showed

that most requirements were functional. While per-

ceptions of the framework varied, both positive and

negative feedback highlighted its strengths and weak-

nesses. The analysis also revealed students’ focus

on user feedback and interaction, reﬂecting concerns

about understanding clients, resolving conﬂicts, and

validating opinions, which aligns with the goals of

CSH and Systems Thinking.

The main limitations of this study include the lim-

ited time available for training, as participants had

only one class to practice applying the CSH frame-

work, which may have impacted their understanding

and conﬁdence. Additionally, with only 36 partici-

pants, the ﬁndings cannot be generalized beyond our

speciﬁc context. Lastly, while we translated the ex-

ample studies from English to the participants’ native

language, this process may have introduced misun-

derstandings that affected their comprehension of the

CSH framework.

We hope that this experience will contribute to the

ongoing discussion of approaches to Systems Think-

ing and Critical Systems Heuristics in computing,

particularly in software engineering. This way of

thinking can be a valuable difference for future pro-

fessionals in the ﬁeld who operate in an environment

of constant change and evolution. It encourages criti-

cal thinking in contrast to traditional mechanistic ap-

proaches. Therefore, it is important to stimulate Sys-

tems Thinking in software engineering education to

better prepare students for the complexities of their

future careers.

For future work, it is important to continue inves-

tigating the use of the CSH framework. One possi-

ble alternative is to employ the CSH framework in

the elicitation phase with participants who are already

familiar with requirement elicitation processes. This

approach would allow for a focused exploration of

the CSH framework without the added complexity of

teaching the entire elicitation process. Additionally,

Integrating Systems Thinking into Software Engineering Education: A Teaching Experience

553

incorporating other System Thinking modeling tools,

such as Causal Loop Diagrams, Inﬂuence Diagrams,

and Simulations, alongside the CSH framework could

be explored to determine if they yield enhanced re-

sults in the requirement elicitation process.

ACKNOWLEDGEMENTS

We thank all the participants in the empirical study

and USES Research Group for their support. The

present work is the result of the Research and De-

velopment (R&D) project 001/2020, signed with Fed-

eral University of Amazonas and FAEPI, Brazil,

which has funding from Samsung, using resources

from the Informatics Law for the Western Ama-

zon (Federal Law nº 8.387/1991), and its disclo-

sure is in accordance with article 39 of Decree No.

10.521/2020. Also supported by CAPES - Financing

Code 001, CNPq process 314797/2023-8, CNPq pro-

cess 443934/2023-1, CNPq process 445029/2024-2,

Amazonas State Research Support Foundation - FA-

PEAM - through POSGRAD 24-25, and Amazonas

State University through Academic Productivity Pro-

gram 01.02.011304.026472/2023-87.

REFERENCES

Andersson, C., Karlsson, L., Nedstam, J., Host, M., and

Nilsson, B. (2002). Understanding software pro-

cesses through system dynamics simulation: a case

study. In Proceedings Ninth Annual IEEE Interna-

tional Conference and Workshop on the Engineering

of Computer-Based Systems, pages 41–48.

Barcellos, M. P. (2020). Towards a framework for con-

tinuous software engineering. In Proceedings of the

XXXIV Brazilian Symposium on Software Engineer-

ing, SBES ’20, page 626–631, New York, NY, USA.

Association for Computing Machinery.

Boehm, B. and Mobasser, S. K. (2015). System think-

ing: Educating t-shaped software engineers. In 2015

IEEE/ACM 37th IEEE International Conference on

Software Engineering, volume 2, pages 333–342.

Borges, J., Lahass, T., Apolin

ario, A., J

unior, P. S., and Bar-

cellos, M. (2024). Unveiling the landscape of system

thinking modeling tools use in software engineering.

In In Proceedings of the XXXVIII Brazilian Sympo-

sium on Software Engineering, pages 47–57, Porto

Alegre, RS, Brasil. SBC.

Cabrera, D., Colosi, L., and Lobdell, C. (2008). Systems

thinking. Evaluation and Program Planning, 31:299–

310.

Daun, M., Grubb, A. M., Stenkova, V., and Tenbergen,

B. (2022). A systematic literature review of require-

ments engineering education. Requirements Engineer-

ing, 28:145 – 175.

Donaires, O. S. (2006). A critical heuristic approach to the

establishment of a software development process. Sys-

temic Practice and Action Research, 19:415–428.

Duboc, L., McCord, C., Becker, C., and Ahmed, S. I.

(2020). Critical Requirements Engineering in Prac-

tice . IEEE Software, 37(01):17–24.

Huang, T. and Fang, C.-C. (2022). Applying system dy-

namics approach for optimizing software release deci-

sions. In 2022 2nd International Conference on Com-

putation, Communication and Engineering (ICCCE),

pages 54–57.

Magnus Ramage, K. S. (2020). Systems Thinkers. Springer

London.

Manduna, W., Goede, R., and Drevin, L. (2022). Incorpo-

rating various perspectives in using instant messages

in teaching programming: A critical system thinking

perspective. Systems Research and Behavioral Sci-

ence, 39.

Mendonc¸a, G., Filho, I. P. D., and Guedes, G. (2021).

A systematic review about requirements engineering

processes for multi-agent systems. In 13th Inter-

national Conference on Agents and Artiﬁcial Intelli-

gence, pages 69–79.

Moreira, A., Leiﬂer, O., Betz, S., Brooks, I., Capilla, R.,

Coroama, V. C., Duboc, L., Fernandes, J. P., Hel-

dal, R., Lago, P., Nguyen, N.-T., Oyedeji, S., Penzen-

stadler, B., Peters, A. K., Porras, J., and Venters, C. C.

(2024). A road less travelled and beyond: Towards

a roadmap for integrating sustainability into comput-

ing education. In Proceedings of the 2030 Software

Engineering workshop, FSE ’24, Porto de Galinhas,

Brazil.

Nayeri, M. D., Khazaei, M., and Alinasab-Imani, F. (2020).

The critical heuristics of iranian banking credit sys-

tem: Analysis of the antithetical opinions of the ben-

eﬁciaries. Systemic Practice and Action Research,

33:363–392.

Niu, N., Lopez, A. Y., and Cheng, J. R. (2011). Using

soft systems methodology to improve requirements

practices: An exploratory case study. IET Software,

5:487–495.

Ulrich, W. (2005). A brief introduction to critical sys-

tems heuristics (csh). In Web site of the ECOSENSUS

project, Knowledge Media Institute (KMI), The Open

University, Milton Keynes, UK.

Wermelinger, M., Hall, J. G., Rapanotti, L., Barroca, L.,

Ramage, M., and Bandara, A. (2015). Teaching soft-

ware systems thinking at the open university. In 2015

IEEE/ACM 37th IEEE International Conference on

Software Engineering, volume 2, pages 307–310.

Williams, D. W. and Kennedy, M. (1999). A framework

for improving the requirements engineering process

effectiveness. INCOSE International Symposium, 9.

CSEDU 2025 - 17th International Conference on Computer Supported Education

554