There were only two programming group projects I had when I was in school. One was software engineering (and that was our Junior year). We learned software engineering, development models, etc, etc... we were then given a list of requirements, verbally, that we had to write down.
I would have certainly preferred fewer group projects at the undergrad level. Of course, a certain amount of programming should be required in each course. There is no substitute.
In my experience, the biggest problem is that too many of the professors don't really know the tools, environments and (sometimes) the languages they're supposed to be teaching. With all of the online instruction available now, all of the top schools appear to be providing their students with the necessary background information (eg how to use emacs, NetBeans, whatever) and decent programming exercises. Its a bit sad that this level of instruction doesn't appear to filter down very far (eg SICP has been around for >10 years, but most AI/Lisp teaching is incredibly misguided).
We could of course ask questions, but the professor did not provide typed up requirements. I liked that. We were given a list of ins and outs, and had to come up with the rest.
Based on my experience working at one university and being a research assistant at another, you won't ever see that at the larger universities. The professors actually spend quite a bit of time creating/revising their classes and everything (AFAIK) has to be in writing and approved by some quality control type people prior to the start of instruction. I've been a (paid) guinea pig for this type of thing.
I imagine what happened in your case is that the professor did have all of the requirements written up in advance. He then graded you based on how many of those requirements you were able to extract. Having you extract the requirements from him verbally is certainly an excellent exercise (esp for small / medium sized projects). I just wish their was more "exploratory programming" (or extreme programming) going on outside of research labs.
One thing I have noticed with the program where I went (for easy of explanation, a satellite of the main campus that was hosted at a community college)
If life provides you the opportunity to attend a top school at some point, I would highly recommend taking it! Not only do the top schools provide you with more and better job/career opportunities, but the course content and selection is vastly superior. When I started at USC, I thought that I knew the basic outline of the rabbit hole (using the Alice in Wonderland cliche/analogy). I certainly didn't everything in detail, but I felt that I could at least be conversant in most areas of compsci especially in my main area of interest (algorithms / algorithm analysis). I had a general familiarity with most of it.
Boy was I wrong. Linear programming, semi-definite programming, PSPACE-Complete complexity class... I hadn't even heard of these terms... and this was only the first class! This wasn't supposed to happen after I had taken 20 or more CS courses, spent two years working part-time at a university, and three years in "industry". I had barely stuck my head into the cave thinking that I knew something... humility is sometimes thrust upon us (or perhaps through us)!
our problem is that all of us were very smart (as told my a professor) so we butted heads a lot. Like my other post, you get a lot of smart people in a room and you get lots of conflict.
Actually, I think the notion that too many smart people leads to conflict is wrong. I've worked with groups where I was certainly the smartest guy (>90% of the time at Boeing!) and where I was not even close to the smartest -- especially when Adleman and/or Kempe are part of the group! In my experience, a group of "truly" smart people tend to get along just fine (at least as well as the average group).
The problem is when you have a group with a couple of smart people, two or three people who think they're smart, and the rest are average or just hanging on to a job (and probably don't care). The problem here is that you can't convince the "I think I'm so damn smart" types that they're wrong, and invariably, they will somehow be the tech lead or the manager's friend. And if you haven't spent some time dealing with this type of person, you can often see problems with their idea (or you might have a better idea), but you are unable to convince people to change things. This is especially true when first starting out because you haven't spent much time articulating the pros and cons of various approaches or playing devils advocate.
Of course, all of this is exacerbated on your first big project because the diamonds in the rough are still rough.