La letteratura e la pratica dello sviluppo del software (in molti progetti) tendono a proporre determinate attività per fornire software affidabile. Queste attività sono apprese dall'esperienza del settore o dai consigli e dalla visione elaborati da diversi pensatori di metodologia. È prassi comune eseguire attività di pianificazione, analisi e progettazione (con qualsiasi altro nome) all'inizio delle principali attività software.
La programmazione software è un'attività che potrebbe trarre beneficio dalle conoscenze acquisite eseguendo tali attività. La programmazione non è solitamente il punto di partenza (o l'unica attività) in un progetto serio. I team di sviluppo sono solitamente composti da persone che ricoprono ruoli diversi. La programmazione è solo uno di questi ruoli.
Il ruolo dell'analista aziendale è di aiutare nel processo di scoperta, documentazione e convalida dei requisiti aziendali dal punto di vista degli stakeholder e dei clienti, i modellatori di dati costruiscono l'ERD per soddisfare tali requisiti, gli architetti determinano l'ambiente ottimale e l'integrazione i metodi per fornire la soluzione, i DBA ottimizzano la progettazione del database, i programmatori lavorano sulla consegna del codice e possono produrre prototipi di sistema per sollecitare il feedback iniziale dei clienti, ecc.
Gli strumenti tecnici come i diagrammi UML possono essere utilizzati da diversi ruoli in varie fasi del ciclo di vita del sistema per documentare il modo in cui il sistema è impacchettato, parti del modello a oggetti, flusso (i) di processo, ecc.
Come indicato da @ Raythal, il processo di determinazione dei requisiti non viene eseguito isolatamente dai clienti (a meno che non si stia creando un nuovo strumento o prodotto) e il processo di analisi ha una natura iterativa in progetti non banali. La relazione tra IT e cliente finale non deve fermarsi dopo che l'analisi del sistema è terminata. In effetti è bene avere un coinvolgimento controllato del cliente durante l'intero ciclo di vita del progetto. Il ruolo di Project Management dovrebbe facilitare l'interazione tra i membri del team appropriati e il cliente e dovrebbe osservare gli interessi di entrambe le parti nel farlo.
Il contenuto del documento che hai menzionato nella tua domanda è ciò che conta. Dovrebbe contenere informazioni sufficienti per tutte le parti coinvolte per fornire i risultati corrispondenti. Ad esempio, un modellatore dati non può creare un modello dati corretto senza regole aziendali. Uno sviluppatore non può produrre un prototipo se i flussi del processo aziendale sono / sono sconosciuti e così via.
In pratica non è raro vedere le applicazioni iniziare in modo non organizzato, tuttavia, questa non è la pratica da seguire se conta l'affidabilità.
Troverai molto di più sulla risposta alla tua domanda sotto l'argomento "ciclo di vita dello sviluppo del software" e in particolare "Ingegneria dei requisiti / Gestione".