← Neueste Arbeiten
💻 computer science

Understanding Undesirable Attributes of Requirements Engineers: Insights from Practitioners

Diese Studie identifiziert und kategorisiert siebzehn unerwünschte Attribute von Requirements Engineers – die sich über Kommunikation, Domänenwissen, Persönlichkeit und technische Fähigkeiten erstrecken – durch Befragungen und Interviews mit Praktikern und bietet konzeptionelle Karten, die Fachleuten helfen sollen, ihre kollaborativen Praktiken zu reflektieren und zu verbessern.

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

Veröffentlicht 2026-06-02
📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

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

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich einen Requirements Engineer als einen Übersetzer vor, der zwischen zwei sehr unterschiedlichen Gruppen steht: den Menschen, die ein Problem haben (den Stakeholdern), und den Menschen, die die Lösung bauen (dem Softwareteam). Seine Aufgabe ist es, die vagen Träume und Bedürfnisse der ersten Gruppe zu nehmen und sie in klare, schrittweise Anweisungen für die zweite Gruppe zu verwandeln.

Dieses Paper ist wie ein „Benutzerhandbuch dafür, was man NICHT tun sollte“. Während viele Studien uns sagen, was einen großartigen Übersetzer ausmacht, stellte diese Forschung eine andere Frage: „Welche spezifischen schlechten Gewohnheiten oder Eigenschaften lassen einen Requirements Engineer bei seiner Arbeit scheitern?“

Hier ist eine Aufschlüsselung der Ergebnisse unter Verwendung einfacher Analogien:

Die Untersuchung: Die Experten fragen

Die Forscher haben nicht nur geraten; sie sind herausgegangen und haben 18 erfahrene Software-Profis (wie Projektmanager und Ingenieure) aus Brasilien gefragt. Sie baten diese Experten, die fünf wichtigsten Dinge aufzulisten, die einen Requirements Engineer schlecht in seinem Job machen.

Anschließend interviewten sie 11 dieser Experten, um die ganze Geschichte zu erfahren: Warum ist das schlecht? Wie zeigt sich das?

Die Ergebnisse: Die „Schlechte Eigenschaften“-Karte

Die Experten identifizierten 17 spezifische schlechte Eigenschaften. Die Forscher ordneten diese in vier Hauptgruppen oder Kategorien ein und erstellten eine visuelle Karte (Abbildung 1 in der Arbeit), um zu zeigen, wie sie zusammenhängen.

Betrachten Sie diese vier Gruppen als die vier Arten, wie eine Brücke einstürzen kann:

  1. Kommunikationsprobleme (Das defekte Walkie-Talkie)

    • Das Problem: Dies war die häufigste Beschwerde. Es geht nicht nur darum, zu sprechen; es geht darum, wie man spricht.
    • Die Analogie: Stellen Sie sich ein Team vor, das ein Haus bauen will, aber die Person, die für die Blaupausen zuständig ist, in Rätseln spricht, nie ans Telefon geht oder wütend wird, wenn man um Klärung bittet.
    • Wichtige schlechte Eigenschaften: „Schwierigkeiten in Beziehungen“ (schwierig in der Zusammenarbeit) und „Mangel an Kommunikation“ (Informationen nicht teilen). Das Paper stellt fest, dass, wenn man nicht weiß, wie man die richtigen Fragen stellt, man sowohl seine Beziehungen als auch seine Kommunikation beschädigt.
  2. Mangelndes Domänenwissen (Der Tourist in einer fremden Stadt)

    • Das Problem: Der Ingenieur versteht das Geschäft, für das er arbeitet, nicht.
    • Die Analogie: Stellen Sie sich einen Koch vor, der angeheuert wurde, um ein traditionelles italienisches Gericht zu kochen, aber er hat keine Austehnung darüber, was Pasta ist oder wie ein Restaurant funktioniert. Er mag vielleicht etwas Köstliches kochen, aber es ist nicht das, was der Kunde bestellt hat.
    • Wichtige schlechte Eigenschaft: „Mangelndes Geschäftswissen“. Wenn der Ingenieur die Ziele des Unternehmens nicht versteht, kann er die Bedürfnisse des Kunden nicht korrekt übersetzen.
  3. Mangelndes technisches Wissen (Der Fahrer ohne Karte)

    • Das Problem: Der Ingenieur kennt die Werkzeuge oder die Regeln der Softwarewelt nicht.
    • Die Analogie: Es ist wie ein Reiseleiter, der die Sprache des Landes, das er besucht, nicht kennt oder nicht weiß, wie die örtlichen Züge fahren. Er kann das Team nicht effektiv führen, weil er das Gelände nicht versteht.
    • Wichtige schlechte Eigenschaft: Nicht die spezifischen Praktiken oder Dokumente zu kennen, die für Software-Anforderungen benötigt werden.
  4. Persönlichkeit (Die Gewitterwolke)

    • Das Problem: Wie der Ingenieur denkt, fühlt und handelt.
    • Die Analogie: Stellen Sie sich ein Teammitglied vor, das eine „Gewitterwolke“ ist – immer resistent gegen Veränderungen, negativ oder unmöglich zu verhandeln. Selbst wenn sie das technische Zeug beherrschen, vergiftet ihre Einstellung die Stimmung im Team.
    • Wichtige schlechte Eigenschaft: Das Paper erwähnt Eigenschaften wie „beeindruckend“ (wahrscheinlich im Sinne von arrogant oder prahlerisch) oder eine starre Persönlichkeit, die neuen Ideen gegenüber resistent ist.

Das große Fazit

Das Paper kommt zu dem Schluss, dass es nicht nur darum geht, klug zu sein oder Code zu beherrschen, um ein guter Requirements Engineer zu sein. Es geht vor allem darum, wie man sich mit Menschen verbindet.

  • Es ist nicht nur „Gut vs. Schlecht“: Die Forscher fanden heraus, dass „schlecht“ zu sein nicht einfach das Gegenteil von „gut“ ist. Zum Beispiel ist ein „guter“ Ingenieur proaktiv und verhandelt gut. Ein „schlechter“ Ingenieur ist nicht einfach nur „passiv“; er könnte aktiv gegen Veränderungen resistent oder feindselig sein. Dies sind unterschiedliche Dimensionen des Verhaltens, keine einfachen Schalter.
  • Das systemische Problem: Die schlechten Eigenschaften sind nicht nur individuelle Fehler; sie sind wie Risse im Fundament des gesamten Teams. Wenn der Übersetzer (der Ingenieur) nicht kommunizieren oder das Geschäft verstehen kann, läuft das gesamte Projekt (das Haus) Gefahr, in sich zusammenzustürzen.

Kurz gesagt: Wenn Sie ein erfolgreiches Softwareprojekt wollen, brauchen Sie einen Requirements Engineer, der ein großartiger Zuhörer ist, die Geschäftswelt versteht, die technischen Regeln kennt und eine Persönlichkeit besitzt, die dem Team hilft, zusammenzuarbeiten, statt es auseinanderzureißen.

Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?

Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.

Digest testen →