Craig:

There is, of course, the classic book "Essential Data Flow Diagramming" by Menamin and Palmer.

The basic idea is to assume a world of perfect technology.  For example, a business has a requirement to, for example, calculate sales tax on a purchase.   In a world of perfect technology, a majical button would suddenly appear to the user.  And the user would simply press the majical button and the sales tax would be instantly calculated: No programming to implement sofware, no database links, no servers - nothing but majic.  (Of course, one can argue that in a world of perfect technology, the button would not even be necessary, just telapathic though, but I wont go there.)

The requirement to calculate sales tax is essential - it is technology independent and is a requirement even if the business has no computers.   All the implementation requirements are non-essential - they exist only because of imperfect technolgoy (i.e., the lack of a majic).  What the BA needs to do is come up with a comprehensive, integrated understanding of the essential functions and, especially, how they all interrelate.  This then gives the logical framework into which all implementatiion considerations are properly pigeonholed.

Craig, the difficulty in understanding the concept of "essential functions" is that the BA needs to be really counter cultural.   The BABOK , for example, teaches things like there are system requirements - which occur within a software system, and there are business requirements.  Not true: Some essential requirements (i.e., business requirements) are implemented by computer, and some are not.   This confustion results in questions like "What is the difference between a business requirements spec and a functional requirements spec?"

Tony

Tony

I don't find any of the Structured ANalysis techniques to actually be in conflict with agile approaches to work.  I think an initial context diagram is essential also.  Maybe even a layer or two down as well.  It can provide a context to the requirements as you move forward.

I do think that in the context of an iterative development you can park the 'keep the solution out of the requirements' concept, as requirements can evolve and respond to the system as it emerges.

For example; your dev team deliver a particular style of search for looking up ice cream shops online.  Why not leverage that search tool when specifying a search for gelato vendors?

Craig:

The problem is is that the Agile folks largely espouse the UML techniques - not DFSs (including Context Diagrams).   This is a tremedous roadblock to focusing on the essential - as the topmost essential in functional modeling is identification of inputs and outputs and there ain't no UML technique that seriously addresses inputs and outputs.  

No one gets it:  the Agile modeling battle cry of  "model just enough" is just a cutesy sound bite that upon any critical evaluation holds no water at all.

Tony