Al Davis spoke as a keynote at RE’10 (www.re10.org) titled “Requirements: A Textbook Example of Goals Displacement”. He started by giving us a definition of Goals Displacement: the process by which the means used to achieve a goal become more important than the goal itself.
What I love about Al’s talks is that he is always entertaining, no matter the topic and he tells great stories. This talk was no different in that he explained the problem of goals displacement with an example where he was leaving a secure facility and the security guard asked to look in his briefcase. Afterwards, he asked the guard what his goal was in searching his bag and the guard responded “to make sure you don’t have cameras or tapes”. Well Al’s point here is that the actual goal is really to ensure their materials are secure, but the guard just isn’t thinking at that level (and it probably wasn’t explained to him at that level!). So the goals in this story are displaced.
Among the reasons Al gave for why we have goal displacement: it’s easier to document how a goal is accomplished than what it is, it’s easier for people to follow rules, and it’s easier to train others on what they need to do (would the guard really be able to translate the goal into his job?). But the risk is that in not understanding the real goals, you achieve the wrong goal instead of the real goal. But he contends that if we understand the real goal, then we increase likelihood that the results create sufficient value for the users.
So then he suggests our focus in the requirements field should be on really understanding what the customer wants and what adds value for them. And as many of us recognize, this is really a question marketing aims to answer. So wouldn’t one think we would have much more overlap between requirements engineering and marketing?
He would love to see in the future that papers talk about how the requirements topics researched relate to revenue growth or market share. Further he put out a 2015 challenge – for organizations to start research efforts now (assuming it takes 5 years to do it!) to measure a correlation between their proposed requirements topic (about language, process, method, models etc.) and customer value.
Well the reason I loved this talk is it’s quite different than what we usually hear spoken at these conferences. Everyone is typically focused on their latest cool research area, but without regard to whether it adds any real value in the practical world.
Our related work:
Beyond my opinions above on Al’s thoughts – it turns out that his comments are very aligned with our methodology at ArgonDigital. I’ve given a few talks on business objectives and how you can use them to select what features you actually build based on which ones contribute the most to the business objectives. In 2009 we gave a talk at REFSQ’09 which I summarized here where I defined the Requirements Object Model (ROM) and how features trace to business objectives. We have since done some work on something we call Objective Factors which are statements of how a feature contributes to the business objectives (it seems I’ll have to write a separate blog on those, or my IEEE RE’10 abstract will be published soon on this). In addition James wrote a related blog that looks at user adoption metrics as an assessment of success of your project – relevant in that if users don’t adopt your software, it didn’t provide customer value.
