Tecniche essenziali per individuare i requisiti mancanti?

Question

Una bozza iniziale delle specifiche dei requisiti è stata completata e ora è il momento di fare un bilancio dei requisiti, rivedere le specifiche . Parte di questo processo consiste nell'assicurarsi che non vi siano lacune significative nelle specifiche. Inutile dire che le lacune portano a stime altamente imprecise, l'inevitabile portata si insinua più avanti nel progetto e alla fine una marcia della morte.

Quali sono le tecniche valide ed efficienti per individuare i requisiti mancanti e impliciti?

• Questa domanda riguarda le tecniche pratiche, non consigli generali, principi o linee guida.
• I requisiti mancanti sono elementi cruciali per la completezza del prodotto o del servizio, ma non pensati o dimenticati,
• I requisiti impliciti sono qualcosa che gli utenti o i clienti presumono naturalmente diventino una parte standard del software senza che sia necessario richiederlo esplicitamente.

_{Sono felice di visitare nuovamente la risposta accettata, a condizione che qualcuno invii una soluzione migliore e più completa.}

Answer 1

valuta il ciclo di vita degli elementi del modello rispetto a un modello generico / generale come

acquisition --> stewardship --> disposal

• sai da dove proviene ogni entità e come la inserirai nel tuo sistema?
• sai dove risiederà ogni entità, una volta acquisita, e per quanto tempo?
• sai cosa fare di ogni entità quando non è più necessaria?

per un'analisi più dettagliata del ciclo di vita delle entità nelle specifiche, creare una matrice CRUDE per le principali entità nei requisiti; questa è una matrice con le operazioni / applicazioni come le righe e le entità come le colonne. In ogni cella, inserisci una C se l'applicazione crea l'entità, R per letture, U per aggiornamenti, D per eliminazioni o E per "quotazioni"; "E" comprende C, R, U e D (la maggior parte delle app di "manutenzione tabella principale" saranno Es). Quindi controlla ogni colonna per C, R, U e D (o E); se ne manca uno (tranne E), capire se è necessario. Le righe e le colonne della matrice possono essere riorganizzate (manualmente o usando l'analisi di affinità) per formare gruppi coesivi di entità e applicazioni che generalmente corrispondono a sottosistemi; questo potrebbe aiutare la distribuzione fisica del sistema in un secondo momento.

È anche utile aggiungere un " Utente " colonna entità alla matrice CRUDE e specificare per ogni applicazione (o caratteristica o area funzionale o qualunque cosa si desideri chiamare gli aspetti di elaborazione / comportamentali dei requisiti) se accetta input dall'utente, produce output per l'utente o interagisce con il utente (per questo utilizzo I, O e N, e faccio sempre dell'utente la prima colonna). Questo aiuta a identificare dove saranno richieste le interfacce utente per l'immissione dei dati e i report.

l'obiettivo è verificare la completezza delle specifiche; le tecniche di cui sopra sono utili per verificare se il ciclo di vita delle entità è "chiuso" rispetto alle entità e alle applicazioni identificate

Answer 2

La comunicazione continua, frequente, schietta e bidirezionale con il cliente mi sembra la principale "tecnica" per quanto mi riguarda.

Answer 3

Dipende.

Dipende se vieni pagato per consegnare ciò che hai detto che consegneresti o per consegnare software di alta qualità al cliente.

Se il primo, elimina semplicemente le ambiguità dalle specifiche e costruisci ciò che hai accettato. Cerca di stare lontano da tutto ciò che non è misurabile (come "veloce", "freddo", "scattante", ecc ...).

Se quest'ultimo, ciò che Galbeciano ha detto + tempo o semplicemente tagliare tutto ciò che non è assolutamente critico e costruirlo il più rapidamente possibile. La produzione ha un modo straordinario di illuminare ciò che ti sei perso in Analysis.

Answer 4

Ecco come trovare i requisiti mancanti.

1. Suddividi i requisiti in piccoli incrementi. Veramente piccolo. Qualcosa che può essere costruito in due settimane o meno. Troverai molte lacune.

2. Dai la priorità a quelli che sarebbe meglio avere prima, cosa c'è dopo a ciò che non ha molta importanza. Scoprirai che alcuni dei riempimenti vuoti non avevano importanza. Scoprirai inoltre che alcuni dei "requisiti" originali " sono semplicemente desiderabili.

3. Discuti le differenze di opinione su ciò che è più importante per gli utenti finali e perché. Due utenti avranno tre opinioni. Scoprirai che alcuni utenti non ne hanno idea e nessuno dei loro "requisiti" sono richiesti. Scoprirai che alcune persone non hanno la spina dorsale e le cose che non sono abbastanza coraggiose da dire ad alta voce sono "necessarie".

4. Ottieni un consenso solo sui primi due o tre. Non discutere di ogni sfumatura. Non è possibile immaginare un software. Non è possibile per nessuno immaginare come sarà il software e come lo useranno. Requisiti della maggior parte delle persone sono descrizioni di come la lotta per aggirare i processi aziendali inadeguati con cui sono bloccati oggi.

5. Costruisci prima la parte più importante e con la massima priorità. Dai agli utenti.

6. GOTO 1 e ripeti il ??processo.

" Aspetta, " dite, " Che dire del budget complessivo? " Che ne pensi? Non puoi mai conoscere il budget complessivo. Procedi come segue.

Guarda ogni incremento definito nel passaggio 1. Fornisci un prezzo per incremento. In ordine di priorità. In questo modo qualcuno può scegliere quanto o quanto vuole. Non esiste una stima di bilancio grande, spaventosa ", con molti zeri". È tutto negoziabile.

Answer 5

Ho usato una metodologia di modellazione chiamata Behavior Engineering (bE) che utilizza il testo della specifica originale per creare il modello risultante quando si dispone del modello, è più facile identificare sezioni mancanti o incomplete dei requisiti.

Ho usato il metodo su circa sei progetti che vanno da meno di un centinaio di requisiti a oltre 1300 requisiti. Se vuoi saperne di più, suggerirei di andare a www.behaviorengineering.org alcuni articoli davvero validi sulla metodologia .

La società per cui lavoro ha creato uno strumento per eseguire la modellazione. Il tasso di lavoro per creare effettivamente il modello è di circa 5 requisiti per un principiante e un esperto di circa 13 requisiti l'ora. La cosa bella del metodo è che non hai bisogno di sapere davvero nulla del dominio per cui sono state scritte le specifiche. Usando solo il testo dell'utente come nomi e verbi, il modellatore troverà lacune nel modello in un periodo di tempo molto breve.

Spero che questo aiuti

Michael Larsen

Answer 6

Che ne dici di costruire un prototipo?

Answer 7

Mentre leggevo tonnellate di letteratura sui requisiti software, ho trovato questi due libri interessanti:

• Frame dei problemi: analisi e amp; Strutturare i problemi di sviluppo del software di Michael Jackson (non un cantante! :-).

• Requisiti software pratici: un manuale di contenuto e stile di Bendjamen Kovitz.

Questi due autori si distinguono davvero dalla folla perché, secondo la mia modesta opinione, stanno facendo davvero un ottimo tentativo di trasformare lo sviluppo dei requisiti in un processo molto sistematico, più simile all'ingegneria che all'arte o alla magia nera. In particolare, la definizione di Michael Jackson di quali siano realmente i requisiti - penso che sia la più pulita e precisa che abbia mai visto.

Non farei un buon servizio a questi autori cercando di descrivere il loro approccio in un breve post qui. Quindi non lo farò. Ma cercherò di spiegare, perché il loro approccio sembra essere estremamente rilevante per la tua domanda : ti consente di ridurre la maggior parte (non tutti, ma la maggior parte!) Dei tuoi lavori di sviluppo dei requisiti all'elaborazione di un gruppo di check-list * che ti dice quali requisiti devi definire per coprire tutti gli aspetti importanti del problema dell'intero cliente. In altre parole, questo approccio dovrebbe minimizzare il rischio di perdere requisiti importanti (compresi quelli che spesso rimangono impliciti) .

So che può sembrare magia, ma non lo è. Ci vuole ancora un notevole sforzo mentale per arrivare a quelle "magie". check-list: devi prima articolare il problema del cliente, quindi analizzarlo a fondo e infine dividerlo nei cosiddetti "frame dei problemi"; (che vengono forniti con quelle liste di controllo magiche solo quando corrispondono strettamente ad alcuni tipici frame di problemi definiti dagli autori). Come ho detto, questo approccio non promette di rendere tutto semplice. Ma promette sicuramente di rendere il processo di sviluppo dei requisiti il ??più sistematico possibile.

Se lo sviluppo dei requisiti nel tuo progetto attuale è già abbastanza lontano dall'inizio, potrebbe non essere possibile provare ad applicare l'Approccio ai problemi a questo punto (anche se dipende molto da come sono organizzati i tuoi attuali requisiti). Tuttavia, consiglio vivamente di leggere quei due libri: contengono molta saggezza che potresti essere ancora in grado di applicare al progetto attuale.

Le mie ultime note importanti su questi libri:

• Per quanto ho capito, il signor Jackson è l'autore originale dell'idea di "frame di problemi". Il suo libro è piuttosto accademico e teorico, ma è molto, molto leggibile e persino divertente.

• Mr. Il libro di Kovitz cerca di dimostrare come le idee del signor Jackson possano essere applicate nella pratica reale. Contiene anche tonnellate di informazioni utili su come scrivere e organizzare i requisiti effettivi e i documenti sui requisiti.

Probabilmente puoi iniziare dal libro di Kovitz (e fare riferimento al libro di Mr. Jackson solo se hai davvero bisogno di scavare più a fondo sul lato teorico). Ma sono sicuro che, alla fine, dovresti leggere entrambi i libri e non te ne pentirai. : -)

HTH ...

Answer 8

Sono d'accordo con il galiziano. La tecnica descritta è molto più efficiente di "aspettare che il cliente ci urli contro" approccio.