Very interesting discussion indeed, seeing things from differing points of views.

1. The term ' requirement' is used so often and in so many different situations, that applying some context and segregation is helpful. Not merely for the sake of partitioning, but because they're valid thoughts to consider. If one can divide solution requirements into functional and non-functional with a fairly clear divisional understanding of each, then why not the same for business and stakeholder requirements ? The former is for the entire enterprise entity and the latter is for a sub-set of it, yet the first question that must be asked of a stakeholder requirement is ' what does this do for the business ? '. So, while there should be a requirement connection and flow from the top-down, it should be validated. 

2. The DFD technique is generally used by tech folks and theres no mention of it in the Enterprise Analysis Chapter in BABOK. What if other techniques were to be used, how would this fit in with the non-partitioning model ? 

Cheers all, 

Hi Engle,

I like your example - it's exactly right in that the different BABOK classes are different types of requirements, not different levels or 'partitions' of a single requirement type.

For enterprise analysis, the first step is usually coming up with a list of "things" or business needs - then modeling them in various ways to show the relationships between them.  The "things" that are relevant at an enterprise level span a number of different categories, including services, events, capabilities, processes, information, products, etc.  There are different framework or taxonomy structures for organizing the 'list of things' such as Zachman Framework for Enterprise Architeture and National Institute of Standards and Technology (NIST).  From the list (regardless of how you document it), the type of diagram used to show relationships just depends on the perspective that you want to show or communicate.  The Open Group has released version 2 of their ArchiMate meta-model - the link below shows some example meta-model diagrams (using version 1, but still applicable), and there is a diagram on this page that shows how the enterprise business model can be decomposed down. 

http://iea.wikidot.com/meta-model

Other diagram types that show different perspectives are capability models and value-stream models.  Information flows (using DFD notation at the top 1-2 levels) show a limited but still very useful perspective - since information and information integration are very key to any business.  (And I use "limited" to mean targeted to a specific perspective, not to infer any criticism of the diagram because I do find them very useful).

For those readers who are wondering a business architect actually does, there's a good article on BATimes:

http://www.batimes.com/articles/the-bad-ass-ba-business-architect.html

Thank you for highlighting this need.  I have updated the Wikipedia article and hopefully have provided some of the information people commented on.  I tried to identify my additions but no doubt could have done better at it.  Please note that  I was not the original author of the article, was not the one who cited my book Discovering REAL Business Requirements for Software Project Success, had not looked at the article for several years, and to the best of my knowledge was not the author of any of the verbiage in the article prior to the additions/changes I just made.