Jaffar:

A picture is worth a thousand words.  Think of a data flow diagram.  If on your diagram you have a data input coming into a process (alternatively called a function) from an unknown source - that unknown source is a gap in your understanding of requirements.   If you have a data output from a function going to an unidentifiable destination - that unidentified destination is also a gap in your understanding of requirements. 

On a data flow diagram, a process/function box (or circle) can represent either a manual or automated activity.  Therefore, gap analysis is applicable to manual activities just as much as to automated activities.   And manual and automated tasks are accomplished in all areas of an organization.

Tony

The gap is essentially between “where we are” and “where we need to be”: the “as-is” and “to-be” models. Strategy is how you going to close the GAP. From a business requirement perspective, the ‘as-is’ requirements define your current business view.  The ‘to-be’ is also defined in a similar fashion. The strategy is then what needs to be done to close the gap, between the “as-is” and the “to-be”.

You could also draw these on multiple axes, for example technology and requirements (see attached hand drawing). Let say you have two applications, the ‘as-is’ Account Payable (A/P) application has LOW Functionality and the Technology is LOW (runs on old DOS box). The ‘as-is’ Account Receivable (A/R) is really Good (ie HIGH Functionality) and runs on the same DOS box.  The ‘to-be’ quadrant is the (H,H) space at the top right hand. To get to the HH Quadrant, the strategy for A/R is purely to replace the hardware. The strategy for the A/P is it requires a hardware change (the easiest thing) and then a functional change or you could go functional and later some hardware improvements