Quale processo dovrebbero rientrare nelle specifiche del campo, nei requisiti o nella progettazione?

I requisiti software riguardano i requisiti imposti al sistema esternamente e internamente dall'organizzazione. Pertanto, i requisiti dovranno specificare gli elementi di dati che costituiscono interfacce esterne o derivare da flussi di lavoro interni, processi e gestione dei dati. Questi elementi di dati devono essere raggruppati e aggregati in base alle esigenze del processo di specifica dei requisiti.

Ad esempio, se è necessario che un indirizzo postale venga convalidato rispetto a un servizio di convalida esterno, come quello fornito dal servizio postale nel proprio paese, ciò implica chiaramente molte specifiche dettagliate degli indirizzi e il modo in cui sono organizzati. L'aggregazione dei dati, il raggruppamento e le relazioni devono essere parte dei requisiti per descrivere correttamente ciò che i requisiti richiedono.

D'altro canto, il progetto trasformerà gli elementi di dati e i raggruppamenti in campi, record, classi, moduli e tabelle e specificherà i metodi con cui vengono raccolti, convalidati, correlati e aggregati.

È importante riconoscere che la Guida di SWEBOK non definisce i processi. SWEBOK è il Body of Knowledge dell'ingegneria del software: è la raccolta di materiale pertinente per i professionisti dell'ingegneria del software. La Guida allo SWEBOK è progettata per organizzare le conoscenze in categorie logiche in modo che argomenti specifici e riferimenti e risorse associati possano essere raccolti e fascicolati per un facile accesso.

Poiché né lo SWEBOK né la Guida allo SWEBOK sono processi, nessuno dei due fornirà alcuna guida su come fare le cose. Due sezioni sono correlate al modo in cui viene svolto il lavoro: processo di ingegneria del software e modelli e metodi di ingegneria del software. Alcuni dei riferimenti nelle sezioni Software Requirements and Software Design forniranno anche suggerimenti su come eseguire le attività di engineering o progettazione dei requisiti nel contesto di progetti di ingegneria del software.

Da una prospettiva più ampia, c'è anche molta confusione in diversi aspetti del processo di sviluppo del software. Ad esempio, un metodo per ottenere e convalidare i requisiti è la prototipazione e questo è discusso nella sezione Requisiti software della Guida allo SWEBOK. Tuttavia, i prototipi sono anche associati alla progettazione dell'interfaccia utente, nonché all'analisi e alla valutazione della qualità di un progetto - entrambi sono discussi nella sezione Software Design della Guida. La prototipazione è legata sia ai requisiti sia alla progettazione, e sono sicuro che ci siano altre tecniche che attraversano due o più aree di conoscenza.

Se stai cercando di definire il tuo processo, non guardare alla Guida di SWEBOK per aiutarti a farlo. Questo non è lo scopo del documento.

Per quanto riguarda la tua domanda principale:

When it comes to requirements gathering and building a requirements specification, should it include low-level details such as fields and their validation? Or is that typically done in the design phase?

Come la maggior parte delle cose nell'ingegneria del software, dipende.

Abbiamo appreso che, in molti casi, avere sili attorno alle diverse attività e buttare il lavoro oltre il muro non funziona. In effetti, anche Winston Royce nel documento che definiva un metodo a cascata richiamava il fatto che la progressione di un progetto software stava invitando il fallimento e, per avere successo, bisognava avere cicli di feedback tra le diverse attività. / p>

Le tue esigenze informeranno il tuo design. Ma mentre stai progettando, puoi saperne di più sui requisiti. E se stai seguendo un modello di consegna iterativo e incrementale, ogni incremento consentirà il feedback sia sui requisiti sia sulla loro realizzazione nella progettazione, che potrebbe identificare le modifiche a uno o entrambi, man mano che aumentano le conoscenze.