Requirements Debt in AI-Enabled Perception Systems Development: An Industrial RE4AI Perspective
Through a qualitative study of 19 experts from the automotive and research sectors, this paper identifies how the rapid evolution of functional and non-functional requirements in AI-enabled perception systems generates and propagates "Requirements Debt," ultimately threatening the safety, reliability, and certification readiness of these critical systems.
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 you are building a self-driving car. In the old days of software, writing the rules was like writing a recipe: you list the ingredients, the steps, and the expected taste, and once the recipe is written, it stays the same until you decide to write a new one.
But with AI, the car doesn't just follow a static recipe. It learns by tasting thousands of different meals (data) and constantly rewriting its own recipe on the fly.
This paper is about a hidden problem called "Requirements Debt" (ReD). Think of this like financial debt. If you buy something today but don't pay for it, you have to pay it back later with interest. In software, if you make a quick change to the car's "brain" (the AI) but forget to update the official rulebook (the requirements), you accumulate debt. Eventually, the interest (bugs, safety risks, certification delays) becomes so high that the project stalls.
Here is the simple breakdown of what the researchers found, using everyday analogies:
1. The Core Problem: The Recipe vs. The Chef
In traditional software, the "Chef" (the developer) follows the "Recipe" (the requirements) exactly.
In AI, the "Chef" is constantly learning new tricks.
- The Debt: The Chef learns a new way to chop vegetables (a new AI model update), but the Recipe book still says "use a knife."
- The Result: The kitchen is chaotic. The staff (engineers) don't know which rule to follow. The car might stop for a plastic bag because the old rulebook didn't account for the new AI's "imagination."
2. How the Debt Builds Up (Functional Requirements)
The researchers interviewed experts from car companies and found that the "Recipe" gets outdated in seven specific ways:
- The Moving Target (Algorithm Updates): The AI gets smarter every week. It starts predicting where a pedestrian will be, not just where they are. But the rulebook still only asks "Where are they now?" The gap between what the AI can do and what the rulebook says it does is called Semantic Drift. It's like updating your car's engine to a rocket, but the manual still says "it runs on gasoline."
- The New Tools (Sensor Upgrades): Imagine swapping a standard camera for a high-tech 3D laser scanner. The old rules for "how far can we see" are now wrong. If you don't update the rules for how these new tools talk to each other, you get Interface Debt. It's like trying to plug a USB-C charger into an old USB-A port; nothing fits, and the system breaks.
- The Silent Assumptions (New Features): The AI starts doing something cool, like guessing if a driver is sleepy. But nobody wrote that down in the official rules. Later, when the car fails to guess correctly, the team says, "That wasn't in the requirements!" This is Implicit Debt—debt you didn't even know you had.
- The Different Rules for Different Countries: A car sold in Sweden might need to handle snow, while one in Florida needs to handle heat. If the company tries to use one giant rulebook for both, it gets messy. This is Variant Debt. It's like trying to write one travel guide that covers both the Arctic and the Sahara; it ends up confusing and useless.
- The Changing Blueprint (Architecture): The car's brain is changing from a simple list of instructions to a complex, self-learning neural network. The old safety rules (like "check this specific sensor") don't work on the new brain. This creates Architectural Debt. It's like trying to enforce traffic laws designed for horses on a fleet of self-driving Teslas.
- The Speed Trap (Real-Time Needs): The car gets faster at processing data, but the rulebook still says "you have 10 seconds to react." Now the car is reacting in 0.1 seconds, but the rules are outdated. This is Timing Debt.
- The New Computer Power: If you upgrade the car's computer to a super-fast quantum processor, the old tests proving the car is safe are no longer valid. You have to re-test everything, but you keep delaying it. This is Verification Debt.
3. The "Soft" Rules (Non-Functional Requirements)
These are the rules about how well the car behaves, not just what it does. The debt here is even trickier:
- Safety Lag: Safety rules (like ISO standards) are like a slow-moving train. The AI is a bullet train. By the time the safety rules catch up to the new AI, the AI has already changed again. The car is driving in a "safety gap."
- The Black Box (Transparency): The AI makes a decision, but it can't explain why (like a human having a gut feeling). The rulebook demands an explanation, but the AI can't give one. This is Transparency Debt. It's like a judge making a verdict but refusing to say why, which makes the public lose trust.
- Trust Issues: If the car changes its behavior every week based on new data, how can you trust it? If the rules don't track these changes, you get Trustworthiness Debt.
- Scalability: The car is collecting so much data it's drowning. The rules say "handle the data," but the system is clogged. This is Scalability Debt.
4. The Consequences: Why Should You Care?
When this debt piles up, it's not just a paperwork problem. It creates a Quality Erosion Loop:
- Confusion: The team doesn't know what the car is supposed to do.
- Delays: They have to stop and re-test everything because the old tests are invalid.
- Risk: The car might make a mistake because the "rules" it's following are outdated compared to its actual "brain."
- Certification Failure: The government won't let the car on the road because the paperwork doesn't match the reality.
The Main Takeaway
The paper argues that in the world of AI cars, you cannot write a rulebook and then walk away. The rulebook must be a living document that changes alongside the AI.
If you treat requirements like a static stone tablet, you will build up a massive "debt" that will eventually crash the project. Instead, you need a "dynamic ledger" where every time the AI learns something new, the rules are updated immediately. If you don't, you are driving a car with a broken map and a fast engine, heading straight for a cliff.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.