Well, I certainly don't want to step on any toes, but as the person who will
be responsible for maintaining the system, I think I've got some say in the
technologies used.  Would the following be more appropriate?

   1) The system must be platform-independent.
   2) The client tier must be completely decoupled from the business tier
using
open standards and protocols (XML/Soap over http(s)).
   3) The business tier must be completely decoupled from the model tier
using
open standards (ODBC).
   4) We will gradually assume maintainence of the system.  The vendor is
expected to transfer skills to our team members.
   5) System must be scalable.

Is that saying enough?  Seems to me that, for example, "System must be
scalable"  isn't going far enough.  What are the appropriate questions to
ask?

Thanks.

Some of our interviewees have assumed that we would do the QA and we
let that go right by without comment.  I've modified my requirements to
reflect
your suggestion.

Thanks for your comments!

According to Phlip <phlip_cpp@yahoo.com>:

Hmm.  If this were my project, I would select that team to explain just
how they propose to accomplish this particular miracle, and short of
a really convincing detailed explanation, fire their sorry a.ses in favor
of a team that had actually read the requirements and thought about
how to meet them.  The first team has shown evidence that they are
a team of yes-men and yes-women who are more concerned with telling you
what they think you want to hear than actually solving the problem
at hand.  In all probability, they will happily tell you that everything
is hunky-dory while the project smartly marches off the nearest cliff.

That's not to say that their approach wouldn't work with some detailed sets
of requirements - just that it seems hopelessly unrealistic for
this particular set of requirements.  I do acknowledge that I'm not
an expert in this kind of system, but I think even I can tell when
someone is blowing that much smoke at me.  

To take the requirements one by one:

    1) The system must be platform neutral.

This sounds like the kind of issue that requires a design review rather
than an automated test to assure.  Sure, I would expect to see a line
in the overall test plan that specifies acceptance tests to be run on
multiple platforms, but that's not sufficient to assure true platform
neutrality.  You need designers who can identify what technologies
are truly portable across the platforms of interest, and implementers
who know how to distinguish between portable and platform-specific code.

   2) The client/presentation tier must be completely decoupled
   from the business/middle tier.  (I should be able to talk to the
   middle tier via applets, flash, CE, perl, PHP, etc.)

Again, something that is primarily addressed in an architecture
review.  You will probably be able to add tests for individual
communication methods with the middle tier over time, but how
do you plan to test "complete decoupling" of the tiers via an
automated test in week 1?  Send the chief architect an email
asking him/her if there are any hidden dependencies?

   3) The system must be able to support 100,000 users.  (Aside:
   how does that translate into concurrent users? 10%?)

Sounds to me like you will need some sort of load simulator
and enough of the system working that you can generate a sample
workload before you can start to test this.  How do you plan
to automate this in week 1?  Call the stub for "create user"
100,000 times and follow with a couple of transactions?
"Yeah, this test verifies that we can support 100,000 users
as long as only one of them is using the system at a time."

   4) The system will be sold to a variety of organizations, so the
   system must be capable of talking to a plethora of legacy systems
   with no (or  minimum) custom programming.  For example, we
   may need to interface to an existing database for authentication
   purposes.

This sounds like an open-ended requirement that will evolve over
the lifetime of the product into many specific examples.
At project start, the best you can hope for is to have a few examples
of such legacy system requirements and think about what common features
might help support them.  I really want to know how the proposed
automated test is going to measure the amount of custom programming
required to support a given system.

Hi,

I have read some debates on EB and most of them
are against its usage.

But when I look at it the concept of wrapping a record
as an object and the container owning the responsibility to
persist the content to the content sounds very neatfor me.
(Separation of concerns..... )

Can you share on why the concept is flawed ?
Is it the implementation of EB by vendors which
is flawed .. or is it the J2EE specifications that
do not allow vendors to provide a good implementation.

This query is something out of context from the
original post, my apologies.