I read your post. From this, I think you are clear about the 'User Requirements' part. But you are caught in between the 'design phase' and 'implementation' phase. I try to give you how we should go about , from 'conception' of the cool project idea upto 'deployment' of the real web application from the experience I gathered. Please read this carefully.
1.1 Get the user requirements and understand them clearly what the user really wants.
1.2 May be just write down in a textfile what are the requirements the users wants. To reduce the communication gap between you and the user, go for prototyping of the 'real system', how will it look finally, and arrage for a meeting with your professor and discuss, if this is what indeed wanted.
1.3 This is what, some architects call as 'iterative phase', which is nothing but go back and forth (erase and draw again

) the screens, after each meeting with the user ( in your case the professor may be). This may take 3 to 4 trails.
1.4 For the above step, if you have a web page design tool, it is well and good. If not, atleaset, take a notebook and FIRST, draw out the screens and the fields, buttons inside the page etc.
This way, you and the professor are thinking in line, what you are going to deliver. It also make ourself clear first. So from start to end draw all the pages and subpages, subsubpages, subsubsubpages etc, everthing the system is going to show to the user.
Now you have the conception of idea, grew into prototype.
2.1 Findout what are the ENTITIES (tables) needed for the system.
2.2 Define the fields, and primary(secondary) keys, unique fields, not null fields , the type and size of the fields etc of each table.
2.3. Now do the normalization. Think in terms of not repeating the same data in different tables. In other words, if there is a set of 'student information' (name,age,address etc) collect and put them in a separate table and whenever you need this student info , for another table , just use the unique key of this student, in the 2nd table. NOT THE WHOLE INFO AGAIN there.
2.4 When you design the tables, keep the prototype papers,(screens) near you, so that, you know whether your database has the information, the prototype needs. This check is definitly needed. If you do not do this check here , latter you may findout, "Oh, I need to change the table design again, code again, test again and everything will be in a chaos!"
So have clear idea about if the database design is in line with the prototype.
Now we have come upto conception - prototype - database Design
There are 2 ways to design. 1. Top-Down 2. Bottom-Up. TopDown is you identify the bigger component ....to smaller component. Bottomup is smaller component .... to bigger one. Depending upon the need, we should go for one of these. Since you are the ONLY person who is going to do everything(design,development,testing) you go for Top-Down desin.
3.1 Findout what are the DIFFERENT Servlets,Classes you can identify which can have their own functionality separated (almost

) from others. Now you identified the 'LoginServlet' isn't? This has its own work of just getting the LoginInfo and routing to success/failed pages. So stick to that. Let the LoginServlet do that related work alone as its name says. Simillarly TRY to identify other Servlets /classes which can have their own work. This is a broder view of the System. Write down all the Component Names (Servlets/classes).
3.2 Now , within each Class, try to identify the methodNames and member vars they may need. Once again we may change these method signatutes slighlty, when we really implement (code) these methods. But that's ok. But we should do this rough design atleast first. Also note that, when we define the members of one class we may identify another broder component need to be defined. It is ok. Just add to the above list of components.
3.3 Now, while defining the members of the class, try to talk with other component's methods. Now you have some idea about how your bigger modules make use of other's methods for their need.
For example now, you may define a ServletUtilities class which has static methods of all kinds, and other Components may make use of them. You need not go into inner details of each methods.
This is where some people use UML diagrams (especially the class-diagrams). It depends. If you don't know uml it is ok. Even I don't. I just used the class diagrams alone. Since your system is not so big or complex, just write down in your textfile/notebook itself.
4.1 Now try to code/test each broder component seperately.
One thing you have to remember is stick to model-view-control design. Try to minimize the code in Servlets. They are just controlers. No SQL CODE, NO HTML CODE in servlets, NO FORM VALIDATION CODE in servlets. Write separate classes for those work. Let the servlets just call those classes's methods.
Another point is DO NOT write HUGE CODE inside one method. Try to minimize the no. of lines of code within one page for each method, so that you should view the whole code in one page. Try to split into smaller logical components (also helps in code reuse).
First get to work!. You can always do the form validation (javascript/server-side-validationpart latter. First get the functionality done with VALID USER inputs from the html/jsp forms.
This is the stage you should worry about how you want to implement the function etc. Do you get this point?

It is ok, if you think about how am I going to do all this thread-safe, the connection pool part etc. But not too much during the design phase.
This is the practice I use and found useful. This may not be the best one. But it didn't hurt at all

. The time you spend in the above phase are really worth since it reduce all of confusion latter during coding. DO NOT JUMP INTO CODING BEFORE YOU UNDERSTAND the BIG PICTURE and how the small components fit together to make the big picture.
You can view the demo application which I developed for my husbands's office requrements.
http://www.webappcabaret.com/maha/index.html I followed the above procedure and finished it in a short term. Of course I got help from javaranch now and then.

Also note that don't get diverted from your goal. If you see another application, if there is anything useful, just think about the useful part alone, not everthing. Divide the overall time you have for the above phases and see if you can meet them. We may not be correct at all times. But atleast we should have some control of the time. The experience you get from this project will deinitly help you in your next one. Of course , in the next project your development speed will be faster than this one since you can make use of some of your comp for the next.

With best wishes,
Maha anna
[This message has been edited by maha anna (edited November 26, 2000).]