Software Engineers Information Seeking Behavior in Change Impact Analysis - An Interview Study

Software engineers working in large projects must navigate complex information landscapes. Change Impact Analysis (CIA) is a task that relies on engineers’ successful information seeking in databases storing, e.g., source code, requirements, design descriptions, and test case specifications. Several previous approaches to support information seeking are task-specific, thus understanding engineers’ seeking behavior in specific tasks is fundamental. We present an industrial case study on how engineers seek information in CIA, with a particular focus on traceability and development artifacts that are not source code. We show that engineers have different information seeking behavior, and that some do not consider traceability particularly useful when conducting CIA. Furthermore, we observe a tendency for engineers to prefer less rigid types of support rather than formal approaches, i.e., engineers value support that allows flexibility in how to practically conduct CIA. Finally, due to diverse information seeking behavior, we argue that future CIA support should embrace individual preferences to identify change impact by empowering several seeking alternatives, including searching, browsing, and tracing.

💡 Research Summary

**
This paper investigates how software engineers seek information when performing Change Impact Analysis (CIA) in a large, safety‑critical industrial automation project. CIA is a mandatory activity in standards such as IEC 61511 and ISO 26262, requiring engineers to identify all artifacts that may be affected by a change before committing code. While most prior research focuses on source‑code impact, this study concentrates on non‑code artifacts—requirements, design descriptions, test specifications, and related documentation—and on the role of traceability links in supporting CIA.

The authors conducted an industrial case study at a company that develops SIL 2‑certified automation systems with over one million lines of C/C++ code. The development process is tightly coupled with an issue‑tracking system: every change is recorded as an issue, a CIA report (based on a 12‑question template) is attached, and the report must be completed before code is committed. The information landscape includes an issue tracker, a document management system (DMS), a source‑code repository, and an internal intranet.

Four research questions guided the study, focusing on (RQ1) how traceability is used in CIA and (RQ2) what information‑seeking strategies engineers employ. Data were collected through semi‑structured interviews with twelve engineers from the Swedish and Indian sites, representing two analysis units (individuals and teams). The interview protocol covered the CIA workflow, tools used, perceptions of traceability, and difficulties in locating information. Transcripts were coded independently by two researchers, and thematic categories were derived.

Key findings are:

1. Divergent attitudes toward traceability – Approximately 40 % of participants actively use existing traceability matrices and automatically generated links as a primary entry point for CIA. They report that trace links help quickly locate related requirements, design elements, and test cases. Conversely, the majority (≈60 %) consider traceability outdated, costly to maintain, or of limited practical value. Some engineers explicitly avoid trace links, preferring direct communication with colleagues, citing speed and reliability.

2. Multiple, overlapping information‑seeking strategies – Engineers combine four main approaches:

   • Keyword search and filtering in the issue tracker and DMS. Search functionality is perceived as basic; lack of consistent metadata reduces precision.
   • Browsing hierarchical folders and version histories to follow “information scent” cues such as document IDs or comments. This method is thorough but time‑consuming.
   • Asking colleagues (face‑to‑face, instant messaging, or meetings). This aligns with the “principle of least effort” and is especially prevalent in the Indian team.
   • Consulting prior CIA reports attached to similar issues, which often contain useful links to affected artifacts.

3. Preference for flexible, non‑rigid tooling – Participants criticize the current issue tracker for its static web UI and limited advanced search features. They desire a tool that allows seamless switching between searching, browsing, and social querying, rather than a prescribed workflow. The DMS suffers from inconsistent metadata standards, leading to poor findability.

4. Suggested improvements – The authors propose (i) enhancing the issue tracker with natural‑language search, auto‑completion, and visual traceability link representations; (ii) establishing document‑management policies that enforce a unified metadata schema and disciplined version control; and (iii) designing a multimodal CIA support interface that integrates search, browsing, traceability visualization, and social interaction (e.g., “ask an expert” widgets).

Threats to validity include sample bias (only two sites and a limited number of engineers) and reliance on self‑reported behavior, which may differ from actual actions. The authors acknowledge that future work should incorporate log analysis and observational studies to validate the findings.

In conclusion, the study reveals that CIA information seeking is highly individualised; engineers do not rely solely on traceability but blend searching, browsing, and interpersonal communication. Effective CIA support tools must therefore accommodate diverse preferences and provide multiple entry points rather than enforcing a single, rigid process. By doing so, organizations can reduce the time spent locating relevant artifacts, improve the completeness of CIA reports, and ultimately strengthen safety cases for certification. Future research will evaluate prototype multimodal tools in real‑world settings to quantify gains in efficiency and accuracy.