In the 20 years that I have been working in IT, I have seen a shift in the way we try to align business needs and applications. The following diagram visualizes this shift and gives a prediction on what's trending. Note that I see various organizations still working in one of the earlier steps.
At level 1, we see organizations that struggle with issues (or have new objectives), that require changes in the application-landscape. At level 1, these issues are directly translated in solutions. Typical situations: business managers with enough power to order direct implementation specific solutions linked to these issues and needs: 'We want system XYZ installed' or 'Please give us 3 new tables in Oracle DB XYZ, so that we can store data XYZ'. In these situations alignment risks are quite high: IT gives the solution, but this solution might likely not solve the business issues (surprise). (Hence the difference between the purple triangle - 'what we wanted', versus the blue circle 'what we got')
At level 2, we see the first decoupling, where IT-requirements are used. As business analysts, we try to understand the issues, their cause and effect, and come up with traceable implementation independent requirements (functional, non-functional), that than can lead to application design and development.
Working with requirements also supports creating clear priorities. However, depending on the requirement process and content, multiple translations might be required, leading to possible information loss and assumptions. IT-requirements can also result in analysis-paralysis, and Big Design Up Front.
At level 3, we choose a process analysis focus. We try to understand the issues and needs, from a end-to-end process perspective, and looking from various angles: customer, employee, management giving better context and cause & effect analysis of the issues. Various business and process requirements are defined, leading to various process designs, and possible process - application support scenario's and requirements.
I would call this the BPM-approach. Clear process governance / ownership can support this step, but not all organizations are at this process maturity level. I find that risks of information loss and assumptions is relatively small - business people and IT people can understand the process design and the IT-requirements, through a better contextual perspective,
At level 4, we see organizations adopting agile model driven technology (BPMS, BRMS, MDA). The big advantage is typically that in very short time frames, applications can be created, evaluated and adapted : what you see is what you get. However, the optimal use of this technology, does require this level of alignment and sufficient process maturity. Otherwise, expensive technology will end up being used in level 1 or 2.
Level 5 is something new for me, and I am slowing seeing this level appear in some organizations (but still in infant mode, typically). This level is based on Human Centered Design, where customer experience, user experience and employee experience are put centrally. This is still about starting with business issues, but then focusing on human behavior (why are this issues occurring), to what experience do these issues lead, and then trying to find alternatives, test them and iterative refine them, until involved people report sufficiently improved experience and show behavior more in line with business expectations (but these expectations may have shifted, based on new insights during these iterations). As human behavior is difficult to predict, agile research is needed, based on various Design Thinking approaches. It leads to applications that engage.
Where are you in your organization? And perhaps the answer is: at various levels, depending on the business area and type of application. Here Capgemini's Application Layers come into focus, see http://www.capgemini.com/blog/cto-blog/2013/11/technovision-2014-from-train-to-scooter-0
But perhaps we all end up in 5 and 6. And what's 6? What do you think?
