There are many ways and techniques out there to help you approach this task.  It depends also on what tools your organization makes available to you and any standards they may want you to follow.

Having said that, the first step is understanding he current technology and business landscape.  If you want to keep this simple you should:

• Document the existing process/activities performed by the business using a process modeling notation such as BPMN.  You need to document everything (manual and automated processes).  Out of this exercise you'll also get a list of Actor (roles, job titles, etc.) which you should document in a separate document and begin developing your actor descriptions/personas.
• Create a spreadsheet of every application, tool, sharepoint site, excel spreadsheet, or other tool used by any of the actors in their job.  This list can be slowly developed at the same time as the business process map aka once you discover a task or activity ask "how do you do this? what tool do you use?".  I would also annotate the process diagram with this tool informaton.  In the tool list you should add columns for metadata for each tool such as description, high level features, tech lead contact, disposition, comments, etc.

Once you understand the AS-IS or current state you'll begin the process of defining the target state process model (is the business process changes - new tasks, dropped tasks, etc.).  This is the time when decisions will need to be made about the future state of existing applications/tools.  Which ones will be kept as-is, which ones will be modified, which one will be retired and replaced with new ones, etc.

Hope this helps!

Adrian

Hi:

Process modeling leads data modeling, so start there first. 

 A business system consists of software and/or computers.   Do not fall into the trap of thinking that to capture the behavior of automated processes requires a different technique than to capture the behavior of manual processes.    That is a forced, artificial partitioning, the main damage caused by such is that it retards integration efforts - especially on larger scale efforts.  Only one technique is needed.

Do not use process modeling techniques that try to steer you into prematurely thinking about solution.   Thinking solution too early is a sure way to derail essential requirements analysis.   In terms of BUSINESS analysis, its a data flow, not a message, its a process, not an object.  Leave thoughts of messages and objects to development staff.  Remeber, one of the most difficult parts of requirements analysis is to maintain a proper focus.  It has always been my experienced that BA's who are not strongly focused on the essentials largely miss them.

Start top down as much as possible, else, there is a real tendancy to "drown in an ocean of details".   But be aware: business systems at higher levels of abstraction (i.e., at the bigger picture level) are notorious for being non-sequential.  One can not model the non-sequential using a sequence dependent technique.   Many, including some of the "experts",  dispute this very imporportant point saying, in effect, you can, even at the top most levels, identify a sequence (including a start point).   Try to do such yourself.   If you can not, then try data flow diagrams (the only real non-sequential technique suitable for larger scale manual/automated systems behavior documentation).

In conjunction with top down analysis, a critical task is to model scope.   A context diagram is the way to go.

When you are modeling processes, think of the essentials.  A process is defined by it inpts and outputs, which are typically data flows. 

For identified data flows, start a data dictionary.   Not the techie type, but, simply, plain english definitions.   This is the primary input to your subsequent data modeling efforts.

Above all, do not let the techie  types steer you into thinking that requirements analysis requires understanding a bunch of techie stuff, including techie stuff related to how you will proceed in requirements analysis.   For a truely Agile approach, all you really need is a few higher level business oriented data flow diagrams, some entity relationship diagrams, and maybe some screen shots. You can leave all the detailed requirements and the techie stuff to be handled by the developers in coverstations.

Tony