There probably isn't just one answer as it depends on the type of project/initiative, what work has been previously done, the business analyst's understanding of the business/project/systems, etc.

Faced with complex problems and systems, I tend to create an model/game plan of the type of artifacts or techniques I'll use for the given project - Usually it's more than one as each technique or artifact places emphasis on a different view point.

In general, I like to think of business systems (since most solutions involve technology) as doing CRUD on data, in the context of business processes/functions, and governed by business rules.

Data => Logical entity model (along with key attributes when needed)

Process/Function => Process decomposition, context diagram, or high-level process flows

Business Rules => at high-level just note what types of rules might govern/constrict the business and solution: SAFE act, Privacy Acts, etc.

I agree with Tony that you want to begin at a high-level of detail and then work your way to more detail in an iterative manner.  But the focus of the analyst cannot be just one of the areas: data, function/process, business rules.  As BAs, we must focus on all aspects upfront - which one comes exactly first is not as important - just pick one.  If the business wants to talk about data then I'll talk about data first, if they want to talk about functions then we'll follow that route, etc.

It's like sitting down to have a great meal: New York stake, garlic mash potatoes, steamed spinach, and bread rolls.  In the great scheme of things it doesn't really matter which one of the items you sample first since the reality is that you'll try the other ones right after.  The end result is that you'll have a full meal in no time - unless you don't eat your vegetables ('cause you don't like them) and only eat your meat and bread.  That's like always only using data flow diagrams because one doesn't like the other techniques.  Not good.

In summary:

• It doesn't matter what you start with as long as you finish your meal,
• Eat all types of foods (in moderation) and don't stay away from the vegetables,
• Don't bite more than you can chew,
• and remember portion control!

- Adrian

Hello all, and a particular hello to K whom I met in Melbourne last week.

I want to start by saying I really liked Adrians last post on this thread.

Secondly there is a good article in the current edition of Pragmatic Marketing about how to get started as a product manager in a new industry.  As a business analyst is a close cousin of the product manager it's worth checking out for that more strategic (?) perspective.

Thirdly, how does K's approach work with a n-tier architecture? Or a solution where the business layer dominates the architecture over the data layer? The way I (a layperson) understand this architecture is that the data itselfstops being the central source -or foundation - of the system and that it very much gets geared around business goals (processes and functions.)