Individuazione dei requisiti funzionali

Completato

I requisiti sono comunemente noti come funzionali o non funzionali. I requisiti funzionali descrivono che cosa deve fare la soluzione o i suoi comportamenti, mentre i requisiti non funzionali definiscono in genere aspetti non comportamentali della soluzione, ad esempio i requisiti di prestazioni. Questo argomento fa alcune considerazioni sui requisiti funzionali.

Ogni requisito funzionale deve definire chiaramente l'autore, il contenuto e il motivo del requisito. Se il requisito è troppo grande, deve essere diviso in parti più piccole.

Esempio di requisiti funzionali

Gli scenari seguenti descrivono semplici esempi di requisiti funzionali:

  • Un utente che si occupa di vendite deve poter chiudere un'opportunità come persa e quindi acquisire il motivo per cui è stata persa in modo da migliorare le tattiche di vendita per il futuro.

  • In qualità di manager vendite, è necessario poter approvare uno sconto su un'offerta in modo da ridurre il prezzo totale e concedere uno sconto al cliente.

  • Un contabile del personale vuole trovare un metodo che impedisca la chiusura di un batch con articoli in sospeso in modo da non doverlo riaprire successivamente.

Queste situazioni comunicano il chi, il che cosa e il perché di un requisito.

Gli esempi seguenti sono requisiti mal formulati:

  • Le opportunità possono essere vinte o perse.

  • Il prezzo deve riflettere gli sconti.

  • Dall'elenco Articolo batch la selezione del pulsante Chiudi batch, che è il terzo pulsante da sinistra, deve chiudere il batch se non sono presenti articoli che impedirebbero la chiusura.

Quando si raccolgono requisiti di qualsiasi tipo, è utile eseguire il mapping al processo anziché elencare semplicemente funzionalità e funzioni. Creare una storia per un utente e descrivere come potrà usare correttamente il sistema che si sta progettando. È possibile scrivere o disegnare su una lavagna, usare uno strumento per tracciare un diagramma di un processo o usare qualsiasi metodo efficace per il team nella fase di pianificazione in cui ci si trova. Il team sezionerà le parti in elementi operativi più piccoli.

Criteri di accettazione

È importante avere una chiara comprensione di come un requisito è considerato soddisfatto. Spesso, la documentazione relativa al soddisfacimento determinerà se il requisito è abbastanza dettagliato e se ha dimensioni adeguate. Questo approccio è utile anche per i team di test che devono valutare l'implementazione del requisito. Infine, il soddisfacimento del requisito deve essere verificato con lo stakeholder per verificare che sia accurato, in quanto può essere usato per evitare scostamenti rispetto all'ambito. L'Architetto di soluzioni deve cercare criteri di accettazione che non possono essere soddisfatti e quindi negoziare per raggiungere un compromesso realizzabile.

Acquisizione di eccezioni

In genere un requisito semplice, come la chiusura di una transazione, può avere un percorso diretto e solo pochi percorsi di eccezione. Assicurarsi di cercare e identificare queste eccezioni nell'acquisire il percorso corretto. Durante la progettazione, lo scopo principale non è progettare la soluzione per le eccezioni. Le eccezioni devono essere gestite in quanto tali, ma se non vengono identificate, sarà necessario rielaborare la progettazione in un secondo momento. Inoltre, ricordare di acquisire la frequenza dell'eccezione, perché alcune eccezioni vengono gestite al meglio da procedure e/o processi e non da personalizzazioni software.

Come evitare scostamenti rispetto all'ambito

Se non è selezionato alcun ambito, ogni progetto aggiunge l'ambito in base a quanto viene determinato e preventivato. L'Architetto di soluzioni deve cercare con attenzione i requisiti che non rientrano nell'ambito rispetto ai presupposti originali. È necessario usare il processo di governance del progetto per valutare come gestire questi casi dopo averli identificati. Spesso, i requisiti esterni all'ambito accettati per l'inserimento possono comportare un ordine di modifica, a seconda della struttura contrattuale del progetto. Se si ignora il fatto che l'ambito sta aumentando, è possibile causare il fallimento del progetto.

Esercizio - Ricerca dei requisiti funzionali

Verificare il team di Woodgrove Bank e identificare le probabili sovrapposizioni tra i team nella funzionalità necessaria per svolgere il rispettivo lavoro.

  • Crescita aziendale e gestione dei cespiti - Conti commerciali con meno di 1 miliardo di dollari di transazioni annuali. La crescita, in questo senso, si riferisce ai prestiti usati per reinvestire nella società. Questi clienti condividono un gruppo di account manager. Non vengono assegnati a una persona.

  • Fortune 500 - A ogni cliente in questa divisione viene assegnato un account manager senior come contatto principale per tutte le questioni bancarie. Quando una società viene gestita in questa divisione, vi resta, anche se in seguito esce dalla classifica Fortune 500.

  • Gestione portafoglio gruppi - Questo team gestisce i conti padre/figlio di aziende con più organizzazioni raggruppate sotto un'unica categoria.

  • Sviluppo di nuove attività - Questa divisione si occupa principalmente del marketing per le nuove attività. Quando un conto diventa qualificato e attivo, passa al team di gestione appropriato.

  • Settore pubblico/Enti pubblici/Istruzione superiore - Woodgrove Bank è un prestatore privilegiato di molti governi sovrani in tutto il mondo e di università private. Questo team si occupa anche del piccolo gruppo di organizzazioni no profit con alti volumi di clienti gestiti dalla banca.

  • Credito al consumo - Questo è il team più piccolo, perché Woodgrove si concentra su prodotti commerciali. Tuttavia, il credito al consumo per grandi volumi può essere disponibile per singoli casi. Questo team non viene pubblicizzato ai prospect esterni, ma viene usato principalmente dai dirigenti dei clienti aziendali.

  • Gestione delle relazioni - Questo team è composto da membri di ognuno degli altri team per garantire un'esperienza coerente, perché gli account possono spostarsi tra i team e interagire in altri modi. Questo team stabilisce anche le procedure consigliate per gli utenti.