Bug or New Requirement – Does It Matter?
Heather Shanholtzer pointed out in Every Second Counts that several big name websites were brought down on June 30, 2012, as the official global clock was adjusted, the so-called “leap second.”
Was this a bug or a new requirement?
I’m sure you’ve had this debate many times on your projects. And I’m sure very few business analysts have specified that their organization’s software must continue to operate during leap seconds.
- Viewed from the perspective of a business user, this is clearly a bug. Why wouldn’t we expect our software to continue to work effectively, regardless of the behavior of the global clock?
- Viewed from the perspective of many software developers, this could easily be considered a new requirement. Why would we think to code around this exception when it’s not in the requirements?
No matter how complete our software requirements specifications and how thorough our stakeholder needs analysis, there are bound to be overlooked assumptions and dependencies that surface.
As a senior business analyst pointed out to me, whether it’s a bug or new requirement really doesn’t matter. What matters is that the current state needs to change. The jargon of bugs and requirements is designed to indicate who was responsible for the problem: the business analyst, the software developer, or the quality assurance engineer. If we focus instead on identifying and implementing the change, we can let go of the finger-pointing and get down to the important work of fixing the problem.
For all of you with defect management systems that include a root cause of “missed requirement,” this is definitely food for thought!
