How to design/plan for web application development?

Question

I'm interested in learning how to design/plan for web application development, in a multiple developer team scenario.

Assuming the role of "Project Manager/Lead":

1. What "documents" are needed for successful web application development?
2. What UML diagrams are needed and to what degree?
3. In the design/plan phase does each - as per use case - class need to be diagrammed?
4. How detailed (depth and breadth) should the class diagrams be?

If you have any helpful book/website recommendations, please share.

---

Follow-up (Added 11/18/09): What do coders/developers use as a guide during coding i.e. creation of classes, and their respective methods & properties?

If there isn't a complete (yet mutable) list of classes with their methods and properties, doesn't that ambiguity cause heavy reliance on each coders' knowledge/experience, resulting in deviations in code quality/usability/maintainability?

Answer 1

1. In all cases you must have a comprehensive and up-to-date record of the exact requirements. This includes both functional and nonfunctional requirements. It can be a Word document, a spreadsheet, or a specialized requirements system. You just need something that allows you to keep track of all the requirements and how they changed over time. Here's a good source of info and discussion about Agile requirements docs.
2. In my experience, use case diagrams have proved to be important, with component and deployment diagrams also being useful. Class and sequence diagrams can also be helpful, but in most cases I think those should be used more as basic mutable guidelines than immutable development requirements. Classes and methods are typically subject to change (especially if you're using TDD), and if you really want a diagram it's best to update it after code is developed rather that shoehorning your code to fit the diagrams.
3. I don't think each and every class needs to be diagrammed. I think that model class diagrams can be useful to keep track of where data is located, and occasionally some controller and view class diagrams are useful too. But in most of my experiences, the requirements and test cases have been the main source of direction in how the classes are designed, and they're refactored as the system grows and changes.
4. In model classes, I don't think anything more than the attributes are usually necessary. If you're modeling controller classes, it's usually wise to include both the major attributes and methods.