Come organizzare i requisiti come analista aziendale

Un requisito aziendale è un documento formale che definisce le esigenze delle parti interessate per un progetto o un prodotto. Non esiste un formato standard unico per la presentazione dei requisiti aziendali, ma ogni versione dovrebbe descrivere il prodotto o il progetto in modo sufficientemente dettagliato da consentirne la discussione, l'analisi, la documentazione e la validazione.

Un requisito aziendale può essere presentato in uno dei seguenti modi:

• Una tabella o un foglio di calcolo
• Un diagramma (flusso di lavoro)
• Un grafico
• Un modello (diagramma entità-relazione)
• Un prototipo o una simulazione
• Una frase strutturata o un modello di testo

Come organizzare e presentare un requisito aziendale

Di seguito sono riportati i passaggi per scrivere e organizzare i requisiti come un Analista aziendale.

Passo 1) Classifica i requisiti.

• Inserisci ciascun requisito nella categoria di appartenenza.
• Gli stakeholder di natura tecnica dovrebbero visualizzare una categoria di requisiti tecnici, mentre gli stakeholder di natura non tecnica dovrebbero visualizzare una categoria di requisiti aziendali o generici.
• Ciascuna organizzazione dovrebbe decidere quali categorie si adattano ai propri standard.
• La categorizzazione può anche basarsi sul tipo di requisito — funzionale o aziendale — sebbene questa distinzione non sia adatta a tutti i progetti.

Passo 2) Disporre i requisiti.
Raccogli e organizza i requisiti in un ordine logico in modo che le parti interessate possano consultare facilmente il documento e individuare gli elementi mancanti.

Passo 3) Preparare una lista.
Preparare un elenco di requisiti da esaminare, raggruppati in base alle parti interessate che devono approvarli.

Ad esempio, un soggetto interessato con un background tecnico si preoccuperà solo dell'aspetto tecnico del prodotto.

Passo 4) Utilizza identificatori univoci.
If tracstabilire requisiti reciproci è difficile, utilizzare identificatori univoci per farlo tracpiù facile.

Passo 5) Presentare i requisiti utilizzando il metodo preferito dalle parti interessate.
Potrebbe essere necessario presentare lo stesso requisito in formati diversi per interlocutori diversi: uno potrebbe preferire una rappresentazione grafica, mentre un altro potrebbe preferire frasi strutturate.

Passo 6) Preparare un sommario.
Crea un indice di tutti i requisiti. Aiuta le parti interessate track e individuarli rapidamente.

Passo 7) Utilizzare gli strumenti di analisi aziendale.
Usa il Strumenti di analisi aziendale che aiutano a presentare e classificare i requisiti in modo coerente tra le diverse versioni.

Passo 8) Organizzare i documenti dei requisiti per flusso di processo.
Elimina i requisiti non necessari dal documento e organizza quelli rimanenti in base al flusso di processo che supportano.

Passo 9) Mappare i requisiti.
Associa ciascun requisito raccolto a una fase specifica del flusso di processo, in modo che i revisori possano collegare il requisito al flusso di lavoro che supporta.

Passo 10) Utilizza tabelle e punti elenco.
Utilizza tabelle per presentare requisiti complessi e elenchi puntati per evidenziare gli aspetti chiave di ciascuno.

Consigli utili per la stesura e la presentazione di un documento sui requisiti aziendali

Per una migliore presentazione e tracIndipendentemente dal tipo di requisiti aziendali, i seguenti suggerimenti sono utili per qualsiasi analista aziendale (BA).

• La categorizzazione dei requisiti richiede tempo, quindi è opportuno definire un insieme standard di categorie che analisti aziendali, stakeholder, esperti di settore e team tecnici possano riutilizzare in diversi progetti, anziché crearne di nuove ogni volta.
• Prepara ogni requisito tenendo conto del pubblico di riferimento. Comprendi chi sono i principali attori, le persone influenti e i responsabili delle decisioni (stakeholder, personale tecnico, sviluppatori e così via).
• Definisci un requisito alla volta. Ogni requisito dovrebbe essere atomico.
• Evitate ambiguità: non utilizzate qualificatori vaghi come "ecc." o "circa." nella descrizione dei requisiti.
• Non fare riferimento a un requisito che non è stato ancora definito.
• Rimuovere dal documento le affermazioni duplicate e contraddittorie.
• Suddividere i requisiti complessi in punti più piccoli, gestibili e verificabili.
• Descrivere che cosa il sistema lo farà, non come Lo farà: l'implementazione va inserita nella fase di progettazione.

Tecniche comuni per visualizzare i requisiti aziendali

Un muro di prosa è il modo più rapido per perdere un interlocutore. Gli analisti aziendali associano a ogni requisito testuale un elemento visivo, in modo che l'intento sia chiaro a colpo d'occhio. Le seguenti tecniche sono presenti nella Guida BABOK e nella maggior parte delle pratiche di analisi aziendale aziendali.

• Modello e notazione dei processi aziendali (BPMN): I diagrammi BPMN rappresentano i processi aziendali end-to-end con pool, corsie, gateway ed eventi. Il BPMN è ideale per mostrare chi fa cosa e quando.
• Diagrammi dei casi d'uso e Descriptioni: Cattura le interazioni tra attori e sistema e i risultati attesi da ciascun attore. Ideale per backlog basati sulle funzionalità.
• Storie utente con criteri di accettazione: Brevi affermazioni del tipo "Come... voglio... in modo che..." abbinate a criteri del tipo Dato-Quando-Allora. Il formato predefinito nei team agili.
• Wireframe e mockup: Schermi a bassa o media fedeltà prodotti in Figma, Balsamiq, o Axure che rendano tangibili i requisiti dell'interfaccia utente per le parti interessate non tecniche.
• Diagrammi Entità-Relazione (ERD): Mostra le entità dati che la soluzione deve memorizzare e le relazioni tra di esse: un aspetto fondamentale per la creazione di report e per i requisiti di integrazione.
• Diagrammi di flusso dei dati (DFD): Trace come i dati si muovono attraverso processi, archivi e attori esterni, soprattutto in progetti di analisi o integrazione.

Adatta la tecnica al pubblico: i dirigenti rispondono positivamente alle mappe di processo e ai diagrammi del percorso utente, gli sviluppatori ai diagrammi ERD e alle user story, mentre gli utenti finali rispondono positivamente ai wireframe e ai prototipi.

Strumenti comuni per organizzare i documenti relativi ai requisiti aziendali

Una volta che il numero di requisiti supera una ventina, un documento Word smette di essere scalabile. Gli analisti aziendali passano a strumenti appositamente creati che supportano la definizione della baseline, la revisione, tracFacilità e gestione delle modifiche. Di seguito sono elencati i metodi più diffusi nel settore.

• Jira con Confluence: La combinazione predefinita per i team agili. I requisiti sono rappresentati come epiche e storie in Jira, supportati da pagine Confluence che contengono la descrizione e i diagrammi del documento BRD.
• Jama Connect: Piattaforma aziendale focalizzata sulla gestione dei requisiti, la definizione della baseline e la produzione in tempo reale. tracfattibilità per settori regolamentati come quello dei dispositivi medici e quello aerospaziale.
• IBM Engineering Requirements PORTE DI GESTIONE: Strumento consolidato da tempo utilizzato nei sistemi di difesa, automobilistici e di sicurezza critici in cui ogni requisito deve essere traccapace.
• Modern Requirements per Azure DevOps: estende Azure DevOps con revisione, approvazione, definizione della baseline ed esportazione del BRD in stile Word direttamente dagli elementi di lavoro.
• Miro or Lucidchart: Lavagna e strumenti di diagrammazione utilizzati per redigere diagrammi BPMN, diagrammi ERD, percorsi utente e appunti di workshop che in seguito confluiscono nel documento BRD formale.
• Balsamiq e Figma: Strumenti per la creazione di wireframe e prototipi che mantengono i requisiti dell'interfaccia utente in forma visiva anziché testuale.

Scegli il set di strumenti in base alla portata del progetto e alle esigenze di audit. I progetti più piccoli possono iniziare con Confluence e Jira, mentre i programmi regolamentati di solito necessitano di Jama o DOORS per soddisfare tracAudit di fattibilità.

Errori comuni nella presentazione dei requisiti aziendali

Anche un requisito ben studiato può essere respinto se presentato in modo inadeguato. I seguenti errori si riscontrano nella maggior parte delle analisi post-mortem di Business Analyst e sono quelli da evitare durante la fase di revisione.

• Mescolare cosa e come: Scivolareping L'inserimento di dettagli di implementazione nella dichiarazione dei requisiti vincola il team di progettazione a una soluzione prima che l'analisi sia completata.
• Formulazione ambigua: Parole come "veloce", "facile da usare" o "flessibile" non sono verificabili. Sostituiscile con criteri di accettazione misurabili.
• Un unico formato per tutti i soggetti interessati: Presentare la stessa visione a dirigenti, sviluppatori e utenti finali di solito non accontenta nessuno. Adatta il formato al pubblico.
• Mancante traccapacità: I requisiti che non sono collegati agli obiettivi aziendali, agli elementi di progettazione e ai casi di test non possono essere difesi quando arriva una richiesta di modifica.
• Nessuna priorità: Presentare centinaia di requisiti senza MoSCoW, punteggio ponderato o un quadro di riferimento simile costringe le parti interessate a discutere sull'ambito del progetto anziché sul valore.
• Documenti sovraccarichi: Inserire ogni diagramma, registro e motivazione in un unico PDF di 200 pagine significa nascondere i requisiti importanti. Suddividete il documento BRD in sezioni logiche con un indice chiaro.
• Saltareping cancella la sottoscrizione: Presentare il documento BRD senza una fase di approvazione formale lascia spazio a possibili ampliamenti incontrollati dell'ambito del progetto e a scaricabarile nelle fasi successive della realizzazione.

RevConfrontare il documento BRD con questo elenco prima di ogni sessione con le parti interessate permette di individuare la maggior parte dei problemi che altrimenti causerebbero rilavorazioni nelle fasi successive.

DOMANDE FREQUENTI