I asked everyone who will use the application (teachers , administration ...) about their needs and feature they want to see in the application.
Chiamiamo la raccolta dei requisiti. Va bene, ma non essere sorpreso quando questi cambiamenti.
should I draw a sequence diagram & use case diagram to explain to my teacher the application's feature & how it work?
Chiamiamo questo design. Puoi farlo in questo modo. Vale anche la pena di prendere in considerazione una simulazione rapida delle GUI con programmi di pittura o carta e matita. Tendo a farlo prima di ottenere tutto formale. È possibile aggiungere immagini, forbici e nastro. Più riesci a mostrare le persone e più ne senti l'idea e può sollevare i problemi prima piuttosto che dopo. Continua a farlo fino a quando le modifiche non si stabilizzano.
should I start create a database for the application then begin creating the application? (it will be web with Java EE)
Ci sono quelli che permettono al database di essere al centro della loro applicazione. Io non sono uno di loro. Mi piace mantenere le regole e le entità della mia attività al centro. Per me il database è solo un'altra cosa esterna con cui comunico.
Ciò che devi capire in ogni caso è ciò che sarà il tuo modello. Questo è il modo in cui il tuo codice riflette ciò che sta accadendo nel mondo reale. Con un modello solido è facile aggiungere il resto.
Come giustamente osserva Laiv, è meglio fare questi passaggi separatamente. Non pensare a quanto sarà difficile da implementare quando si disegna la GUI. Pensa a ciò di cui l'utente ha bisogno.
Ora, solo perché li fai separatamente non significa che devi farlo a distanza di giorni. Il modo agile di lavorare è quello di spingerli attraverso tutti concentrati sulla cosa più piccola che puoi pensare di fare. Mostralo rapidamente agli utenti e ottieni feedback prima di aggiungere un'altra funzionalità. Fai questo e il tuo design non sarà solo una pugnalata al buio. Ti sentirai come per un design migliore.