Navigating the Conflict Maze: How Traceability Decodes Software Quality Trade-offs
5124_Identifying Requirements Conflicts and Cooperation How Quality Attributes and Automated Traceability Can Help.
Summary
Problem
Method
Results
Takeaways
This paper introduces an automated approach to identify conflicts and cooperation among software requirements by combining Quality Attribute (QA) analysis with Requirements Traceability (RT). By footprinting requirements through test execution paths, the method effectively filters out false-positive conflicts that occur when requirements target disjoint system regions.
## TL;DR
Managing software requirements is often a battle between competing "ilities"—functionality vs. efficiency, security vs. usability. This paper presents a systematic framework that uses **Automated Traceability (RT)** to prove whether perceived conflicts are real or merely "false positives" by looking at where they manifest in the actual code.
## The Problem: The $n^2$ Nightmare of False Conflicts
In complex systems, every new requirement carries the risk of sabotaging an existing one. If you have 100 requirements, there are potentially 10,000 interactions to check. Traditional methods rely on **Quality Attribute (QA)** heuristics (e.g., "Adding features usually slows down performance").
However, the authors point out a critical flaw in this logic: **Location matters.** If Requirement A (a new search filter) and Requirement B (a fast video startup) don't share any underlying code or resources, their theoretical conflict is irrelevant. Without locality data, engineers waste countless hours chasing "ghost" conflicts that would never actually collide in reality.
## Methodology: Marrying Attributes with Footprints
The authors propose a hybrid approach that bridges the gap between abstract requirements and concrete execution.
### 1. The Interaction Model
First, requirements are mapped to standard attributes (ISO 9126). Using a predefined matrix, the system identifies potential conflicts (–) or cooperation (+). For instance, adding "Security" might have a negative effect on "Efficiency."
### 2. Traceability via "Footprinting"
This is the core innovation. Instead of manual mapping, the system uses **Scenario-Based Trace Analysis**. By running test scenarios for each requirement, the tool records which lines of code are touched. This "execution path" is the requirement’s **footprint**.
*Figure: The pipeline from requirement categorization to footprint-based filtering.*
### 3. The Overlap Filter
The system then compares the footprints.
* **Full Overlap**: A definite conflict or synergy.
* **Partial Overlap**: A "gray zone" conflict whose strength is weighted by the percentage of shared code.
* **Zero Overlap**: A false conflict. Even if the attributes are theoretically opposed, they are safely isolated.
## Case Study: The Video-on-Demand (VOD) System
The authors applied this to a VOD system to demonstrate its industrial utility.
Consider two scenarios:
1. **R1 (Auto-play)** vs **R6 (1-second start time)**: Both requirements involve the movie-loading logic. Trace analysis showed a subset overlap. This is a **True Conflict**—the extra logic of R1 might push the startup time of R6 over the limit.
2. **R2 (Text Info)** vs **R6 (1-second start time)**: While R2 adds functionality (traditionally bad for efficiency), its footprint (displaying text) is disjoint from R6 (starting the video stream). This is a **False Conflict**.
*Figure: Visualizing how R1 and R6 overlap while R2 remains isolated.*
## Experiments & Insights: Quantifying Interaction
The study emphasizes that conflict isn't binary. By measuring the **weight** of trace dependencies, developers can prioritize which conflicts to resolve first.
| Attribute | Effect on Efficiency | Effect on Reliability |
| :--- | :---: | :---: |
| Functionality | - | - |
| Usability | +/- | + |
| Security | - | + |
*Table: A snippet of the interaction model showing conservative heuristics.*
The findings show that "Partial overlaps" represent the most common real-world scenario. The less the overlap, the "weaker" the conflict, allowing developers to make informed gambles on performance or reliability.
## Critical Analysis & Future Outlook
**The Takeaway**: This work shifts Requirements Engineering from a documentation exercise to a data-driven analysis of system behavior. By leveraging existing test cases, it provides a "free" way to generate traceability data.
**Limitations**: The primary bottleneck is the requirement for a **testable system**. This method works wonders during iterative development (like Agile), but it is difficult to apply in the very early "napkin sketch" phase before any code or simulations exist.
**Future Prospect**: As we move toward AI-driven development, combining this footprinting technique with LLMs could allow for even more granular conflict detection, potentially predicting overlaps before a single line of code is written by analyzing historical repository patterns.