Abstract
Requirement elicitation, a critical part of project development, is often perceived as a purely technical process. However, this is not always the case. Effective requirement elicitation relies not only on technical acumen but also on an understanding of how human cognition, biases, and behaviors shape the process and what we can do to mitigate the negative influence of these inherent human factors. In this article, we selected three critical human factors: confirmation bias, the availability heuristic, and groupthink. These factors are commonly experienced in requirement elicitation activities. The article delves into the intricacies of these human aspects of requirement gathering and illustrates their impact using examples. We dissect the impact of these biases on requirement gathering, shedding light on the potential consequences that can arise when they go unchecked. Furthermore, we discuss strategies and techniques for mitigating these biases, emphasizing the role of requirements analysts as impartial facilitators.
Introduction
Requirements Elicitation is often considered a merely technical process; however, that is not the case. It is a process profoundly influenced by the intricacies of human psychology, like any process with extensive human engagement. Project success hinges on successful requirements elicitation and management processes; yet, our understanding of how human cognition, biases, and behaviors shape these processes is limited. In this article, we will discuss how some human factors impact requirement elicitation, shedding light on the cognitive biases that can either facilitate or hinder effective requirement gathering.
In software development and project management, requirement elicitation is a critical process for a successful endeavor. It is the source of truth that guides developers and architects, and it serves as a reference point for validation and verification. Interestingly, on the surface of this seemingly technical process lies a complex interplay of human psychology, cognition, and biases that can shape the outcome. Requirements elicitation is not always a matter of carrying out successful elicitation activities; it requires awareness of the various human elements and how they can exert on the process.
While requirements documentation, including user stories and use cases, are the tangible artifacts of this process, we should not underestimate the behaviors of stakeholders, analysts, and project teams that breathe life into these artifacts. Sometimes the intricate dynamics of cognitive biases, group dynamics, and psychological nuances shape the fate of a project.
Confirmation bias
Confirmation bias manifests when individuals seek to interpret information in a way that confirms their preexisting beliefs, values, or assumptions. This type of bias can be pervasive in the context of requirement elicitation. It can lead to stakeholders selectively pushing and emphasizing information that aligns better with their beliefs, values, and assumptions while ignoring conflicting evidence and real business needs. For example, a stakeholder might push requirements that support a preferred solution or view it as potentially resulting in a product not aligned with the real needs.
For example, let’s consider a scenario in which a financial institution embarks on a project to develop a cutting-edge trading platform. The success of this platform is critical, as it has the potential to generate new revenues and provide competitive advantages. The project’s requirements gathering phase is entrusted to a team of stakeholders, including subject matter experts, financial analysts, and risk managers.
One particular requirement for the future trading platform was its ability to execute high-frequency trades with minimal latency, which was put forward by a senior stakeholder, Laura, who has a strong belief in the profitability of high-frequency trading strategies. She believed that this approach would set the platform apart from competitors and secure a dominant market position. During requirements elicitation activities, Laura consistently pushed for low latency and high-frequency trading capabilities. She emphasizes the potential revenue gains, citing successful case studies where similar strategies yielded substantial profits. At the same time, driven by her bias, she downplays concerns raised by other stakeholders regarding the associated risks, regulatory challenges, compliance, and potential negative market impacts.
Laura’s confirmation bias, coupled with her influential role as senior stakeholder, influenced the team’s decision, and subsequently, they decided to prioritize low-latency and high-frequency trading capabilities at the expense of other requirements. The development effort heavily focuses on meeting this particular requirement, allocating the majority of resources and budget to its implementation. With limited knowledge of the business domain and needs, the development team was unable to challenge and identify de-prioritized requirements. Other stakeholders taking part in the elicitation activities have become complacent to Laura’s persistence, influenced by her seniority.
Once the trading platform nears completion and undergoes testing, unforeseen consequences begin to emerge. The intense focus on high-frequency trading has led to neglect of other critical requirements, such as robust risk management and compliance features. The platform, while excelling in executing rapid trades, lacks essential safeguards and risk controls. Consequently, the product was not approved by the financial institution. During the validation and verification processes, shortcomings were pointed out, and the sign-off for the product was not secured. The project, initially seen as a revenue-generation opportunity, turns into a financial loss.
In this example, confirmation bias in requirement elicitation had profound and far-reaching consequences. Laura’s biased belief in a specific requirement, driven by her confirmation bias, led to the neglect of critical requirements that were essential for the long-term success and stability of the financial platform. This example underscores the critical importance of impartial and comprehensive requirements gathering processes.
Availability heuristic
The availability heuristic refers to the tendency to overestimate the importance of information that is readily available to us, easily recalled because of past experiences, or simply inherent to our system of values and beliefs. In requirements elicitation, stakeholders may prioritize requirements that come to mind easily, are talked about more often, or became more visible because of a recent event, even if they are not the most relevant to the business’s needs. This bias can lead to incomplete, biased, or skewed requirements.
Let’s work with an example. A software development team is tasked with developing a new e-commerce platform for a major retail company. The project sponsor, Alex, decided to actively participate in the requirements elicitation process. His main requirement for the future platform is ensuring robust security measures to protect customer data, given the increasing prevalence of cyberattacks on online retailers. He was influenced by a recent incident about a competitor in the same industry experiencing a highly publicized data breach. The breach resulted in millions of dollars in losses and significant damage to the company’s reputation. The incident received high news coverage and social media outrage. Alex is adamant about ensuring such incidents do not occur under his watch.
During the requirements gathering process, the team discusses various security measures, including encryption protocols, secure payment processing, and intrusion detection systems. Driven by the vividness and emotional impact of the recent incident, Alex strongly advocated for allocating a substantial portion of the project budget to security. Alex argued that such a high-profile breach could happen to their company as well if they don’t prioritize security to the maximum extent possible.
The development team, influenced by Alex’s determination, shifted their focus to security. This decision significantly reduced the budget available for other essential requirements, such as user experience improve- ments, the participation of UX designers, and marketing initiatives. As the project progresses, it becomes apparent that the allocation of resources to security has been excessive. The platform’s security measures are robust, but the user experience and marketing efforts to promote it were lackluster. The company’s e-commerce platform, while secure, is difficult to navigate, lacks appeal in usability, and lacks the features that would attract and retain customers. Ultimately, the consequences of the availability heuristic-driven decision become apparent. The company’s new e-commerce platform, while safe from cyberattacks, struggles to attract customers and generate revenue due to the neglect of other critical requirements. Overspending on security, influenced by the vivid memory of a single high-profile breach, leads to financial losses and missed business opportunities.
In this example, the availability heuristic led to a biased decision during requirement elicitation. The project’s sponsor’s focus on a vivid and emotionally charged incident from the recent past resulted in an unbalanced allocation of resources and an overemphasis on a particular technical aspect of the product, neglecting other important requirements. The implications were financially costly, impacting the platform’s overall success. This example underscores the need for a balanced and evidence-based approach to requirement gathering, even in the face of emotionally charged events.
Groupthink
The desire to maintain harmony within a group results in an irrational or dysfunctional decision-making outcome, referred to as groupthink. In requirements elicitation workshops or meetings, groupthink can stifle dissenting opinions and lead to the unquestionable acceptance of ideas. This behavior can have consequences, as requirements might go unchallenged and innovative avenues may remain unexplored.
The example illustrating the availability heuristic, where an emotionally charged incident led to an imbalanced focus on security requirements, could also take place at a group level. Instead of bias originating from the project’s sponsor, it can also emerge as a group consensus. A project team may collectively opt to prioritize security over all other considerations without thorough analysis, discussion, and review from external stakeholders, which can lead to a consensus-driven decision that resembles groupthink. The decision-making process becomes susceptible to biases that prioritize a single aspect at the expense of other requirements. In such a case, the team’s pressure to conform to a consensus view, driven by the fear of conflict and desire for harmony, led to an unbalanced decision that neglected other aspects of the product.
Mitigating cognitive biases
Cognitive biases are inherent to human nature and difficult to recognize and mitigate. However, as analysts, we should become aware of them and reduce their impacts. One efficient technique is to diversify the involvement of relevant stakeholders. Diverse perspectives can help counter confirmation bias and groupthink. Diversifying techniques used in the process of requirement elicitation can also help disrupt anchoring biases and encourage creativity. Having a review process in place where diverse stakeholders can comment and provide feedback on requirements can also help mitigate and scrutinize biases. Encouraging data-driven decisions rather than personal opinions, experiences, or preferences can also reduce the impact of availability heuristics.
Analysts play a crucial role in recognizing and mitigating cognitive biases. They should act as impartial facilitators, guiding stakeholders through the elicitation process while actively identifying and mitigating biases as they arise. Additionally, requirements analysts must maintain open communication channels, ensuring that all stakeholders are engaged and their concerns heard.
Author: Adam Alami
Adam Alami is an assistant professor with Aalborg University, Denmark. He has broad experience in information technology practices. His career began in software development, before progressing to include business analysis and project management. Involvement in major IT transformation projects has for twenty years been the mainstay of his work. His chosen fields of research fit within the broad topic of cooperative, social, and human aspects of software engineering. He has a keen interest in business analysis and contemporary software development practices. He holds a PhD degree in Computer Science from the IT University of Copenhagen, Denmark, a Master degree in Computer Science from the University of Technology (UTS), Sydney, and a Bachelor degree in Software Engineering from the Université du Québec à Montréal. Email: [email protected]. Twitter: @AdamAlamiDK.