Sorry Sonavi

You are working out of my depth.  I never deal with the specifics of design.  It's like telling your mechanic how to fix your car.

I have a hunch that a data flow diagram will suit your needs.  I also have a hunch that the other experts here will refer you to use cases.

Personally, I would skip all of that and just go for boxes and arrows (with some lines indicating the tiers) and then put it in front of the developers and ask what they think.  After all you are all part of one big team and should be working co-operatively.

Greetings Sonavi,

What you are articulating is the "otherside" of the BA dilemma that we all face from time-to-time. Most of us BAs are good at the Business <--> BA interaction; but we do not have the requisite skills to address the BA <---> IT interactions. Other BAs seem to be better at the BA<--->IT interactions and again struggle with the Business<--->BA interactions.

What you are describing in your question above is essentially the MODEL, VIEW, CONTROLLER architecture. VIEW = UI Interface; MODEL = Database and CONTROLLER =  "business application logic". 

There are many books that show how to get from usecases to a MVC architecture. A quick reference is Dough Rosenberg's ICONIX process (see http://www.iconixsw.com/EAICONIXProcess.html). In this book (website) Dough shows how to go from usecase <--> robustness analysis <--> sequence diagrams etc. You need to know some UML - some knowledge of component and deployment diagrams may be needed.  A "DFD Diagram just wont cut it!

When writing user requirements this question normally pops up in the non-functional requirement section under constraints. eg. "The new system must conform to our adopted 3-tiered architecture"

May I suggest that you partner with an IT person, much in the same way you partnered with the business person to capture requirements, and start doing some high-level MVC (UML - diagrams)

All the best!

warm regards,

K