It looks like nobody has responded to this yet, so I'll take a crack at it.

What I've witnessed is that a missing DNC object tends to imply a missing or future requirement. 

That is to say, you've looked at your requirements, and you just can't see where this hole in your model is covered by anything you've been asked to build.  However, once management or the customer gets their hands on a prototype of the application, they're going to say, "Hey, this is pretty neat, but why can't I do..." and then you'll find yourself with a change request that, surprise surprise, fills in a couple of those holes.

Sometimes I see these while going over the requirements docs for the first review, especially when they're boundary conditions (what should I do when this data has/hasn't already been entered before?  What if there are two of these, or worse, 500?  How should I present that?).  This makes requirements meetings with me take a lot longer, but it leads to less frustration among my peers as the delivery approaches and, I hope, a better product.

Other times, they're features to be built in version 2 or 3 of the product.  In these cases I find it helpful to know that some day I'm going to have to add this object to the model (just not today).  Sometimes management finds it helpful for doing long-term planning ("Oh yeah, I didn't think of that.  Good idea.  We'll add that to the schedule for the next version."). 

Mostly, the knowledge that something belongs there but hasn't been defined yet helps me when picking implementations for the surrounding code.   I'm not talking about writing the first version so that all of the support for the 'someday, maybe' features is already in the code.  That road leads to the unemployment line (by way of project failure).  I mean that sometimes the most innocuous-looking changes to a design can make all the difference between a difficult feature request and a simple one.  I think about these when I know ahead of time that a feature is or might be coming.  Thirty seconds spent considering the hypothetical, "Okay, now how would I refactor this code to support a one-to-many relationship here, instead of a one-to-one?" frequently saves me days of rework later on, and costs the current milestone hardly anything at all.

-Jason






--
- Jason