In the class we learn about various software development methods. The
one we focused on, and used to develop our project, was the waterfall
You probably learned the classical Waterfall model, which the person attributed with introducing it to the software development world stated from the start was inappropriate for developing large-scale software systems. You would probably be interested in reading Winston Royce's paper titled Managing the Developemt of Large Software Systems to learn more about the problems with what many people consider to be the Waterfall model.
However, the Waterfall model is good for teaching the software development lifecycle as you go through and can spend time learning about and performing requirements engineering, architectural design, detailed design, implementation, testing, and maintance in very clear, distinct phases.
In our class diagrams, we had to list ALL properties and methods
including private ones. I have read a few books, namely Clean Code,
that say to keep functions as short and focused as possible. It seems
tedious to list every little function in our diagrams if they don't
help other developers out (they're private, no one else will use
them). Plus, I may not think of every tiny function when designing the
program, they may come along when refactoring.
These are all very valid points.
Listing all properties and methods during the design phase, even when using Waterfall, is probably overkill. You should definitely list everything that's public, along with the essential properties. In reality, everything else is an implementation detail that you can obtain by reverse engineering your implementation into diagrams.
Clean Code's advice (I've never read it - I'm just going by what you posted) seems to be fair, and applicable even when using the Waterfall methodology. You can design your classes and methods with respect to the Single Responsibility Principle, separation of concerns, and other principles of SOLID. Waterfall doesn't tell you how to design, just when you need to do it. That said, it is harder up-front as you learn and think of better ways to do it during implementation.
I think this points out the fact that there needs to be iteration between design and implementaion very clearly - a problem that traditional Waterfall doesn't account for.