Tony is raising some good points.

On As-Is

While I feel that there is plenty of situations where a deep as is analysis is not required, it certainly is the cae ofr any major system, BPR or tranforamation project (which are the sort Tony works on.)  Examples of where deep as-is is not required include system upgraes, swapouts and the like, where business provcesses remain stable.  Or migrating a minor paper process online. 

Yes - there is always a point where these things get big enough to warrant the major up front analysis investment.  Sometimes you don't see it until too late.  Balancing risk is part of the process.

But I guess I have seen enough patters in requirements re-appear to realise that systems are a lot simpler than business processes and operations.  And as a result you can deliver systems that are flexible enough to accomodate a variety of process scenarios.  Part of this is about good design.

So, for me, there are plenty of cases where I don't sweat the as-is too deeply.

A word of warning: For you juniors out there - you don't know the patterns and so you have to do your as-is even for minor projects.  Read the next comments to learn more.

As for Partitioning -

A top down approach to requirements gathering, defintoin and analysis is fundamental to doing the job right.  If you go out and ask people about their expectations, needs and requirements you'll get a whole lot of vberlapping, conflicting info with significant gaps.  you'll have also collected a lot of informatin that isn't aligned to the goals of the project.

A classic example; a company wants to introduce an online sales channel.  They start a project and the analyst visits the stakeholders.  Eventually the requiremenst cover the whole value chain from online web sales through to B2B web services for supply chain stuff, integration into your finaancial systems, CRM and more.

Keep the solution within the bounds of the goal and scope.  Come in top down.

And then you will see the logical partitions Tony is referring to.  Maybe use a functiomnal decompostion to see the tree of requirements.  Maybe pull together your DFDs from the top layer and work down.  You can stop well before you get to the system context and you will have done a much better job that most analysis who drill into detail way to early and as a result overengineer the unimportant and miss fundamentals.

What Tony says is right, with some exceptions.  Think top down for a better view of how it all comes together.

Now let me add two more things.

1. Always always ensure you physically see what the users do in their current world so you understand the real issues they face.

2. Always always always ensure you know the value of each and every line in your requirements specs.  By value I mean how it contrbutes to your companies balanced scoreacrd, strategy or whatever other goals it has set out.