← Latest papers
💻 computer science

Understanding Undesirable Attributes of Requirements Engineers: Insights from Practitioners

This study identifies and categorizes seventeen undesirable attributes of requirements engineers—spanning communication, domain knowledge, personality, and technical skills—through practitioner surveys and interviews, providing conceptual maps to help professionals reflect on and improve their collaborative practices.

Original authors: Larissa Barbosa, Sávio Freire, Marcos Kalinowski, Zadia Codabux, Rodrigo Spínola, Manoel Mendonça, Rita S. P. Maciel

Published 2026-06-02
📖 4 min read☕ Coffee break read

Original authors: Larissa Barbosa, Sávio Freire, Marcos Kalinowski, Zadia Codabux, Rodrigo Spínola, Manoel Mendonça, Rita S. P. Maciel

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a Requirements Engineer as a translator standing between two very different groups: the people who have a problem (the stakeholders) and the people who build the solution (the software team). Their job is to take the vague dreams and needs of the first group and turn them into clear, step-by-step instructions for the second group.

This paper is like a "User Manual for What Not to Do." While many studies tell us what makes a great translator, this research asked a different question: "What specific bad habits or traits make a Requirements Engineer fail at their job?"

Here is a breakdown of their findings using simple analogies:

The Investigation: Asking the Experts

The researchers didn't just guess; they went out and asked 18 experienced software professionals (like project managers and engineers) from Brazil. They asked these experts to list the top five things that make a Requirements Engineer terrible at their job.

They then interviewed 11 of these experts to get the full story: Why is this bad? How does it show up?

The Results: The "Bad Trait" Map

The experts identified 17 specific bad traits. The researchers organized these into four main "buckets" or categories, creating a visual map (Figure 1 in the paper) to show how they connect.

Think of these four buckets as the four ways a bridge can collapse:

  1. Communication Issues (The Broken Walkie-Talkie)

    • The Problem: This was the most common complaint. It's not just about talking; it's about how they talk.
    • The Analogy: Imagine a team trying to build a house, but the person in charge of the blueprints speaks in riddles, never answers the phone, or gets angry when asked for clarification.
    • Key Bad Traits: "Difficulty in relationships" (being hard to work with) and "Lack of communication" (not sharing info). The paper notes that if you don't know how to ask the right questions, you break both your relationships and your communication.
  2. Lack of Domain Knowledge (The Tourist in a Foreign City)

    • The Problem: The engineer doesn't understand the business they are working for.
    • The Analogy: Imagine a chef hired to cook a traditional Italian meal, but they have no idea what pasta is or how a restaurant works. They might cook something delicious, but it's not what the customer ordered.
    • Key Bad Trait: "Lack of business knowledge." If the engineer doesn't understand the company's goals, they can't translate the customer's needs correctly.
  3. Lack of Technical Knowledge (The Driver Without a Map)

    • The Problem: The engineer doesn't know the tools or the rules of the software world.
    • The Analogy: It's like a tour guide who doesn't know the language of the country they are visiting or how the local trains run. They can't guide the team effectively because they don't understand the terrain.
    • Key Bad Trait: Not knowing the specific practices or documents needed for software requirements.
  4. Personality (The Storm Cloud)

    • The Problem: How the engineer thinks, feels, and acts.
    • The Analogy: Imagine a team member who is a "storm cloud"—always resistant to change, negative, or impossible to negotiate with. Even if they know the technical stuff, their attitude poisons the team's mood.
    • Key Bad Trait: The paper mentions traits like being "impressive" (likely meaning arrogant or show-offy) or having a rigid personality that resists new ideas.

The Big Takeaway

The paper concludes that being a good Requirements Engineer isn't just about being smart or knowing code. It's mostly about how you connect with people.

  • It's not just "Good vs. Bad": The researchers found that being "bad" isn't just the opposite of being "good." For example, a "good" engineer is proactive and negotiates well. A "bad" engineer isn't just "passive"; they might be actively resistant to change or hostile. These are different dimensions of behavior, not just a simple switch.
  • The Systemic Issue: The bad traits aren't just individual flaws; they are like cracks in the foundation of the whole team. If the translator (the engineer) can't communicate or understand the business, the whole project (the house) is at risk of falling apart.

In short: If you want a successful software project, you need a Requirements Engineer who is a great listener, understands the business world, knows the technical rules, and has a personality that helps the team work together, not one that tears them apart.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →