Raccolta e analisi dei requisiti
Quando non è possibile soddisfare un requisito del cliente con le funzionalità preconfigurate delle app per la finanza e le operazioni, è necessario avviare la fase di analisi. Quando un requisito è indispensabile, allora è necessario prendere in considerazione la personalizzazione.
Raccogliere i requisiti presuppone l'analisi di tutti gli aspetti dei processi aziendali esistenti nonché dello stato futuro dei processi stessi. L'intero processo di raccolta e riconoscimento dei requisiti richiede un approccio altamente scientifico basato su competenze e sulla capacità di prestare attenzione ai dettagli.
È necessario riuscire a descrivere lo stato futuro dei processi aziendali nelle app per la finanza e le operazioni sulla base di una soluzione proposta, in correlazione con le funzionalità preconfigurate.
Il collegamento tra i processi aziendali e i requisiti deve essere sempre esplicito. Si inizia da un livello generale di copertura, ma i requisiti devono essere raccolti in modo dettagliato.
Un processo aziendale è una raccolta di attività e requisiti strutturali correlati e interconnessi tra loro, alcuni dei quali possono essere rappresentati in un diagramma di flusso comprendente punti decisionali e dipendenze.
Un sottoprocesso è il livello di ciascuna funzione di un processo aziendale. La descrizione dettagliata delle funzioni aziendali inizia a questo livello. Un sottoprocesso potrebbe essere dedicato a una singola area funzionale o potrebbe racchiudere anche un'area interfunzionale.
Un requisito include una serie di attività o passaggi all'interno di un sottoprocesso. Le organizzazioni possono utilizzare gli scenari dei casi d'uso per spiegare chiaramente i requisiti. Un caso d'uso rappresenta un modello di comportamento e include una sequenza di attività correlate. Ogni organizzazione deve mantenere l'obiettivo di raccogliere i requisiti nel modo più strutturato possibile.
È importante riconoscere l'importanza di creare e mantenere processi documentati. Verificare di creare, mantenere e aggiornare i seguenti documenti per soddisfare i requisiti:
- Documento progettazione soluzione (SDD): si tratta di una documentazione approfondita del progetto iniziale e dei dettagli della soluzione, rappresentata in un diagramma di flusso end-to-end che mostra tutti gli elementi della soluzione previsti e concordati per l'utilizzo futuro.
- Documento requisiti aziendali (BRD): una volta preparato l'SDD, è necessario rivedere il documento dei requisiti aziendali originale per garantire che siano inclusi tutti i processi e i sottoprocessi aziendali e che siano espressi tutti i requisiti (funzionali e non funzionali).
- Verifica che tutti i documenti siano SMART: dovrebbe essere possibile descrivere chiaramente gli obiettivi del progetto in un formato SMART (specifici, misurabili, attuabili, ripetibili e temporalmente definiti).
- Piano di progetto: un piano di progetto è un documento di roadmap su come raggiungere gli obiettivi nelle fasi di implementazione. Un piano di progetto deve favorire una comunicazione concisa ed efficace. Il piano di progetto deve definire la struttura di suddivisione del lavoro (WBS), che identifica tutto il lavoro che è necessario svolgere per completare il progetto.
- Piano di comunicazione: il piano dovrebbe definire formalmente i destinatari delle informazioni specifiche e il momento in cui devono essere rilasciate.
- Piano di qualità e accettazione: questo piano garantisce l'accettazione dei risultati finali e identifica le dipendenze esterne, poiché queste possono avere un impatto diretto o indiretto sul piano di progetto.
- Piano di gestione delle modifiche: la richiesta di modifica deve essere acquisita in un registro, con informazioni adeguate sul soggetto, sull'oggetto, sul motivo, sull'ubicazione e sulla data della richiesta.
- Revisione dell'analisi corrispondenza-scarto: il documento di analisi corrispondenza-scarto è il documento di input principale per scrivere il documento di progettazione funzionale (FDD). È importante esaminare dettagliatamente il documento di analisi corrispondenza-scarto prima di iniziare con l'FDD.
- Documento di progettazione funzionale (FDD): questo documento descrive le caratteristiche delle personalizzazioni. Il documento può includere elementi come diagrammi di flusso, screenshot, wireframe, nonché contiene un elenco organizzato di requisiti che è possibile usare per lo sviluppo, il test e l'approvazione del cliente. Prima di scrivere un FDD è fondamentale eseguire il processo indicato nella sessione di revisione dell'analisi corrispondenza-scarto.
- Documento di progettazione tecnica (TDD): una volta completato e approvato il documento di progettazione funzionale, il team di sviluppo deve iniziare a redigere un documento di progettazione tecnica. Include informazioni sull'approccio programmatico usato per l'implementazione di un particolare requisito. I TDD sono preparati principalmente dallo sviluppatore per lo sviluppo finale.
- Definizione di scenari di casi d'uso: descrive dettagliatamente un processo aziendale. Consiste in sequenze di attività e include passaggi decisionali e condizionali.