Johanna Rothman writes about frequent builds and automated smoke tests in Build Fast and Fix Fast.  My favorite quote from her post:

"The faster you want the project to go, the more frequently you need to build."

It seems counterintuitive, but it ends up working for the reasons she explains in the blog post.  As stated in my recent review of the book The Goal, the book challenges ideas that are intuitive throughout.  For example, to speed up the factory, the plant manager had to have some workers not do anything for maybe hours per day. 

If you are thinking about trying daily (or more frequent) builds, it is going to take some work but the payoff is there.  Initially the discipline necessary to get your application to a daily build-able state and setting up the automated build and unit tests will take a lot of time and will seem like development would be faster without it.  However you will come to love it the first time it gives you an early warning on what would have been a big problem.

Johanna also writes in GUI Requirements and Text Documents that using a paper prototype is the best method for determining GUI requirements.  She writes, "monolithic requirements documents are too hard to read, too detailed, and insufficiently detailed, all at the same time."  I cannot agree more.  In a recent project I worked on, the use cases totaled 1700 pages.  Unfortunately these were not complete until 1 month prior to when we, the developers, were supposed to be done, but that is another story.  Of those 1700 pages, we probably ignored half since they overspecified, were not detailed enough, or were incomprehensible.  Sad to say, but we could have developed faster by removing the requirements team (which was as large as the development team) and working directly with the end users.