Business Function Models Vs Business Capability Models

The difference between these models boils down to the difference between a “business function” and a “business capability”.  Many organizations use them interchangeably. For e.g. A business capability model may illustrate current-state business functions and also future-state business functions that need to be built to deliver on the business vision.
But there are few folks who would like to draw a clear line of differentiation between the two.  Capability can be defined as the ability to perform actions to achieve specific strategic goals/objectives.

The following links provide interesting reading:
Link 1
Link 2

Hence a business capability is much more than a business function – it encompasses other objects such as Actors, Services, Functions, Processes and Infrastructure.  Examples of business capability are – the ability to service customers through online channels, capability to survive liquidity crisis, etc.

Business Architecture Models

While defining the enterprise architecture of an organization, it is essential to understand the various processes, functions and capabilities of the business. Recently came across the FEA Business Reference Model on Wikipedia. The simplicity of the diagram impressed me.

Every organization has different business areas or LOBs. Each business area has a set of business functions that it performs.  A ‘Business Function Model’ describes these functional areas and sub-functions in a graphical representation. An example of a BFM can be found here. 

Each LOB executes its business functions by following certain business processes.  A business process is an orchestration of different business activities and tasks that may be exposed as SOA services.

Ruminating on Requirements Elicitation

Last night, I was ruminating on the lessons learned during my experience in business architecture, business analysis and requirements elicitation. I think at the broad level, there are 2 kinds of requirements.

The first kind is - Where we know, what we don't know: These requirements are easy to capture since we have an idea about the pain areas of the customer, we know what is the vision of the project, what is being planned to be done, etc. Hence we can ask appropriate questions, dig deeper and after a few iterations of interviews can get a pretty good understanding of the requirements.

The second kind of requirements are - Where we don't know, what we don't know !
Digging out these requirements is the most challenging task - because we never ask the right questions about things that don't know, our past memory/experiences make implicit assumptions on certain things. Such kind of requirements result in last minute suprises and everyone wonders why these points were never discussed or brought out !!!

How do we elicit these requirements? I think the following techniques during requirements elicitaiton would help:
1. Question each and every assumption - both implicit and explicit. Assumptions may not hold true in every scenario. Check if the assumption is valid for the current scenario.
2. Ask 'stupid' questions - Yes, this works !!!...I have seen that often, analyst's refrain from asking questions because they are self-conscious, are afraid of being ridiculed for lack of knowledge in a domain area, etc. i.e. they are afraid of sounding 'stupid'. But clarifying even the simplest doubt could open up a plethora of new requirements.