Analisi dei requisiti formali

L'analisi dei requisiti è un processo che utilizza strumenti come i diagrammi UML.

I diagrammi facilitano la comunicazione e talvolta possono essere utilizzati per generare codice (ad esempio 1 e 2 sotto). Aiutano anche ad aggiungere un livello visivo alla soluzione che potrebbe aiutare un po 'di tempo gli utenti finali e gli sviluppatori (ad esempio 4, 5 sotto).

I diagrammi dei casi d'uso rappresentano una vista ad alto livello dell'interazione e non sostituiscono la descrizione del caso testuale.

Alcuni dei diagrammi molto importanti per mostrare i requisiti e il design sono: 1. Diagrammi delle relazioni di entità 2. Diagrammi di classe 3. Diagrammi di sequenza 4. BPM - Modelli di processo aziendale 5. Diagrammi di flusso della pagina 6. Usa casi

L'analisi dei requisiti è un argomento ampio e può utilizzare anche altri diagrammi. L'importante è che acquisisci e comunichi le tue conoscenze sui requisiti di sistema agli sviluppatori e agli utenti finali.

Ci sono suite di strumenti che possono convalidare alcuni dei diagrammi sopra (ad esempio 1,2). Alcuni strumenti possono creare automaticamente applicazioni Web da (1 o 4).

Sì, i diagrammi sono importanti e vengono utilizzati in alcuni progetti.

I problemi scolastici sono troppo semplificati per l'apprendimento. Quindi non puoi dare giudizi di valore basati su di essi sull'utilità nel mondo reale. La maggior parte delle persone che fanno i requisiti Analysis non sono programmatori e sicuramente non potrebbero esprimere il requisito nel codice. In terzo luogo, questi sono più utili quando si eseguono progetti complessi di grandi dimensioni, quindi l'esperienza delle persone che lavorano su oggetti più piccoli può indicare che sono poco utili quando l'esperienza delle persone che lavorano su progetti di tipo navetta spaziale potrebbe essere diversa.

L'ultimo grande progetto a cui ho lavorato aveva un documento di requisiti iniziali di oltre 800 pagine (che alla fine è diventato molto più grande) a volte avere un diagramma rende più facile capire la parola scritta. Aiuta anche a mantenere le persone in termini di processo che deve essere creato e aiuta a prevenire stupidità come richiedere al software di ottenere l'approvazione da un manager per la spesa di budget per un progetto di oltre $ 1 milione ma nessun requisito che dice tu cosa devi fare se rifiuta il progetto. Quando usi un approccio strutturato, è più probabile che tu veda tutti i pezzi che penso.

Queste tecniche sono sempre appropriate per tutti i progetti, ovviamente no. I progetti agili tendono ad adottare un approccio meno complesso per iniziare e queste tecniche potrebbero essere percepite come perditempo. Da quello che hai scritto, sospetto che tu sia qualcuno che è più comodo con l'approccio agile e quindi non può usare queste tecniche o vederle nei progetti su cui lavori. Ciò che è critico nell'apprenderli per voi potrebbe essere più il processo di pensiero analitico che li fa piuttosto che i diagrammi stessi.

Sì, queste cose hanno valore nel mondo reale.

Non li usi sempre tutti e non li elimini sempre alla perfezione, ma sono tutti strumenti utili per modellare il dominio del problema e assicurarti di costruire la soluzione corretta.

Ciascuno di questi artefatti esiste perché sono migliori modi per documentare ciò che sta accadendo rispetto al testo normale. Se l'inglese semplice funzionasse meglio, lo useremmo. (Dove l'inglese semplice funziona meglio, noi usiamo i requisiti testuali!)

Non lasciarti ingannare dalla semplicità di queste cose nell'ambiente di apprendimento. Possono diventare piuttosto complessi nel mondo reale. Oppure, in alternativa, a volte sono complessi non - e quindi diventano un modo semplice per trasmettere la comprensione.