Perché di Business e Requisiti Funzionali sono di Vitale importanza per il Successo di un Progetto

In un processo di sviluppo del prodotto, uno degli aspetti più importanti di qualsiasi progetto di successo è ottenere i requisiti di destra. E molti progetti falliscono perché le parti interessate non riescono a comprendere la differenza tra i requisiti aziendali e i requisiti funzionali.

Il successo finale e il fallimento di qualsiasi progetto dipendono dalla qualità dei requisiti. Sebbene raramente sia dichiarato in modo così semplice, la maggior parte dei progetti software fallisce a causa della minore enfasi posta sulla gestione dei requisiti.

Nel settembre 1999, la NASA ha perso la sua $125 milioni di Mars Climate Orbiter quando ha cercato di entrare in orbita, a circa 100 chilometri a troppo vicino a Marte. La missione fallì a causa della scarsa gestione dei requisiti: non è stato discusso in precedenza nella fase se il “software di navigazione” richiedesse unità metriche o unità imperiali.

Il risultato: Specifiche incompatibili; il sistema di controllo dell’assetto è stato specificato utilizzando unità imperiali ma il suo software di navigazione ha utilizzato unità metriche.

Quindi, ottenere i requisiti giusti e utilizzarli al massimo è fondamentale per il successo di un progetto.

Nel campo dello sviluppo di prodotti software, l’importanza e la rilevanza della parola “Requisiti” sta aumentando con la crescente popolarità delle metodologie di sviluppo software agile. Anche uno dei punti menzionati nel Manifesto Agile spiega la metodologia come uno che valorizza:

“Software di lavoro su documentazione completa”

Ottenere i requisiti giusti è fondamentale, sia che si lavori in metodologia Agile o Waterfall.

Business vs Requisiti funzionali – Definizione e suoi tipi

Prima di approfondire i requisiti aziendali vs requisiti funzionali diamo un’occhiata alla definizione e ai tipi.

Secondo l’Istituto internazionale di analisi aziendale, un requisito è:

• Una condizione o capacità necessaria da uno stakeholder per risolvere un problema o raggiungere un obiettivo.
• Una condizione o capacità che deve essere soddisfatta o posseduta da un sistema o da un componente di sistema per soddisfare un contratto, uno standard, una specifica o altri documenti formalmente imposti.
• Una documentata rappresentazione di una condizione o capacità come in (1) o (2)

Basato sul dominio del problema e la metodologia di un Analista di Business (BA) funziona con i seguenti sono i vari requisiti, di cui le più importanti sono: requisiti di business e requisiti funzionali.

In questo blog, esploreremo la differenza tra i requisiti aziendali e i requisiti funzionali. È imperativo comprendere la differenza in modo da offrire al business una soluzione ideale che si prenderà davvero cura del problema.

Quali sono i requisiti aziendali

Perché un cliente ha bisogno di un’app?

Questa informazione può sembrare inutile a molti perché il cliente è pronto a pagare per costruire un app. Quindi, perché dovrebbe importare a voi per ottenere le ragioni?

Beh, se sei appassionato di costruire prodotti di qualità e offrire esperienze senza soluzione di continuità ai tuoi clienti, allora dovresti preoccuparti dei “perché” tanto quanto fai dei “che cosa” e dei “come”.’

E quando inizi a concentrarti sulla parte “perché” di un progetto, significa che ti stai prendendo cura dei requisiti aziendali.

Requisiti di business per lo sviluppo del software ciclo di vita si occupa di requisiti di alto livello o vuole di un’organizzazione, che permette al business di raggiungere i suoi obiettivi finali, visione, e gli obiettivi.

Di solito descrivono cosa dovrebbe fare un sistema o una soluzione. Essi danno la portata di un bisogno di business o di un problema che dovrebbe essere affrontato da un particolare progetto o compito.

Esempio di requisiti aziendali

ParcelKiosk è uno dei nostri clienti che ci ha contattato per ottenere un’applicazione web progettata e sviluppata per offrire migliori servizi di consegna pacchi ai clienti. Mentre ci avvicinavano, abbiamo iniziato la discussione con un parametro importante: analizzare le esigenze aziendali.

Che cosa pensi che il requisito di business potrebbe essere per questo servizio di consegna pacchi web app?

Potresti trovare un parametro importante come la sicurezza. Tuttavia, anche se la sicurezza è un fattore vitale, non è un requisito aziendale. Non si costruisce un servizio come ParcelKiosk senza sicurezza in mente, ma la creazione di servizio solo per il gusto di fornire la sicurezza—non è l’obiettivo finale.

Che dire del collegamento di una gamma di servizi di corriere e clienti?

Questo ha un senso migliore come requisito aziendale rispetto alla sicurezza perché descrive ciò che il servizio farà. Tuttavia, è questo il motivo per ottenere il servizio web costruito, o è davvero una funzione del servizio?

Qui ci sono alcuni possibili motivi (requisiti di business) per costruire ParcelKiosk:

• Offrire una soluzione più intelligente per misurare, selezionare, e spedire pacchi
• Forniscono funzionalità per tenere traccia e gestire la loro consegna e servizi di pick-up
• i tempi di consegna e i feedback dei clienti

vedi la differenza tra la connessione di una gamma di servizi di corriere e di clienti o di sicurezza, e le reali esigenze di business?

I seguenti punti possono essere notati qui w.r.t requisiti di business:

• I requisiti aziendali sono sempre scritti dal punto di vista del cliente.
• Sono requisiti di sistema ad alto livello ma orientati ai dettagli.
• Non sono obiettivi organizzativi ma aiutano un’organizzazione a raggiungere i suoi obiettivi. Con l’adempimento di questi requisiti aziendali, l’organizzazione raggiunge i suoi obiettivi generali.

È abbastanza chiaro ora che i requisiti aziendali spiegano la parte “perché” di un progetto: “perché” un particolare progetto deve essere costruito, cioè quali benefici l’organizzazione mira a raggiungere attraverso la realizzazione di un progetto specifico.

Documento sui requisiti aziendali (BRD)

Un documento sui requisiti aziendali descrive le esigenze aziendali di alto livello. Il target principale di un BRD è il cliente e gli utenti. I requisiti aziendali sono documentati nel BRD. Un documento di requisiti aziendali ben scritto aiuta a raggiungere l’obiettivo desiderato di costruire un prodotto di successo entro il limite di tempo stabilito.

Ha i seguenti elementi:

• La visione del progetto
• Obiettivi del progetto
• il Contesto di sfondo o del progetto
• Ambito del progetto
• Stakeholder identificazione
• Mappa Requisiti di Business
• l’Ambito della soluzione
• vincoli del Progetto: Periodo di tempo, costo del progetto e risorse disponibili

Requisiti aziendali Esempio del documento – Perché Chrysler PT Cruiser è stato etichettato come “Eroe a zero”

Chrysler Group non si è concentrato molto su BRD e ha proseguito la produzione del proprio PT Cruiser, causando molti mal di testa per l’organizzazione. Diamo un’occhiata a come il loro documento requisiti aziendali fallito:

• Identificazione delle parti interessate: Chrysler Group ha identificato la maggior parte delle parti interessate abbastanza bene. Erano a bordo con i fornitori e il team di produzione del PT Cruiser. Tuttavia, i due importanti stakeholder che mancavano includevano il cliente finale che acquistava il veicolo e i concessionari che vendevano l’incrociatore.
• Vincoli di progetto: Chrysler ha svolto un buon lavoro quando si trattava di stakeholder di alto livello che fornivano e supervisionavano la costruzione. Tuttavia, ciò che mancavano era mettere in discussione la tempistica per la produzione, rispondere alle domande dei clienti o dei rivenditori come prezzo, disponibilità del modello e domanda.

Supponiamo che il BRD di Chrysler includesse tutti i requisiti delle parti interessate, che quei ritardi imprevisti nella consegna del prodotto (obiettivo di consegnare automobili alla concessionaria entro il 2001) avrebbero potuto essere influenzati con largo anticipo rispetto alla produzione e che le esigenze degli utenti finali sarebbero state giustificate.

Suggerimenti per la Scrittura di un Business Requisiti di Modello di Documento (BRD)

Ora che avete una conoscenza di base di ciò che un BRD deve compiere, è possibile seguire i sotto indicati suggerimenti per assicurarsi che si scrive un business eccezionale documento dei requisiti.

• Pratica forte requisiti elicitazione
• Usare un linguaggio semplice, senza voce passiva e il gergo
• Ricerca progetti passati
• Convalidare la documentazione
• Integrare grafica

Quali sono i Requisiti Funzionali

Requisiti Funzionali, come suggerisce il nome, descrivere le funzionalità del software o di un prodotto. Queste sono le funzioni che il sistema deve eseguire per soddisfare i requisiti aziendali.

Includono dettagli tecnici, calcoli, manipolazione ed elaborazione dei dati e altre funzionalità particolari che caratterizzano ciò che un framework dovrebbe raggiungere.

Se non si dispone di requisiti funzionali chiari per comprendere la tecnicità del progetto, durante il progetto, non sarà possibile rispondere se le decisioni prese dai team di sviluppo/progettazione/test sono corrette.

“Non riuscendo a scrivere una specifica è il singolo più grande rischio inutile si prende in un progetto software.”~Joel Spolsky

Se un dettaglio funzionale non è allineato agli obiettivi di business, potrebbe causare il fallimento del progetto.

Requisiti Funzionali Esempio

Uno dei grandi beni di largo consumo giocatori si avvicinò al Netto di Soluzioni per lo sviluppo di applicazioni mobili progetto in grado di migliorare l’efficienza della catena di fornitura.

Questo gigante di FMCG ha iniziato un progetto nel 2001, che mirava a responsabilizzare le donne rurali generando opportunità per loro di vendere prodotti e guadagnarsi da vivere.

Il cliente voleva che il nostro team di progetto rinnovasse la propria app mobile esistente in modo da automatizzare la catena di fornitura e il processo di ordinazione portando le donne rurali e i distributori su un’unica piattaforma digitale.

Miravano a migliorare il tasso di adozione, consentendo digitalmente agli imprenditori e risolvendo gli attriti nel customer journey esistente (tutti questi sono requisiti aziendali).

Quando si tratta di requisiti funzionali, abbiamo iniziato a discutere le funzionalità dell’app richieste con il cliente, che erano:

• Integrazione con fornitori di terze parti
• Aggiornamenti stock in tempo reale
• Order placement

Il cliente presumeva che queste funzionalità sarebbero state sufficienti per risolvere gli attriti nell’attuale customer journey, migliorando così il tasso di adozione.

Tuttavia, mentre discutevamo i requisiti funzionali con il nostro cliente, ci siamo resi conto che se non identifichiamo l’attrito nel percorso di un cliente esistente e misuriamo i livelli di alfabetizzazione digitale per i nuovi utenti di app, sviluppare un’app sarebbe inutile.

La soluzione che Net Solutions ha fornito

Abbiamo applicato l’approccio del Design Thinking e condotto ricerche etnografiche per valutare la disponibilità digitale degli imprenditori e comprendere le lacune nel percorso degli utenti dell’app esistente.

Abbiamo trascorso una giornata con tutti gli stakeholder per identificare ulteriormente i loro problemi.

Utilizzando l’approccio di Design Thinking, siamo stati in grado di capire quali funzionalità dovrebbero andare nella nuova app. Inoltre, questo approccio ha fatto capire al nostro cliente che il modo migliore per andare avanti con la gestione del progetto è di eseguirlo in modo “graduale”.

Il risultato:

La ricerca etnografica e la mappatura del percorso all’interno della nostra metodologia di design thinking ci hanno aiutato a costruire una nuova app con funzionalità progettate e convalidate dagli stakeholder che alla fine la utilizzeranno, rendendolo uno dei notevoli esempi di requisiti funzionali.

I seguenti punti possono essere notati qui w.r.t requisiti funzionali:

• I requisiti funzionali sono sempre scritti dal punto di vista del sistema e degli stakeholder.
• Le specifiche dei requisiti funzionali sono molto più dettagliate.
• È attraverso l’adempimento dei requisiti funzionali che viene sviluppata una soluzione efficace, che soddisfa le esigenze e gli obiettivi aziendali del cliente.

Quindi, i requisiti funzionali spiegano il “come” parte di un progetto, cioè i requisiti software e come la soluzione sarà in grado di soddisfare le esigenze dell’organizzazione.

Documento sui requisiti funzionali

Il documento sui requisiti funzionali delinea le funzioni necessarie per soddisfare le esigenze aziendali. Queste funzioni sono documentate nel documento dei requisiti funzionali (FRD) o nel documento delle specifiche dei requisiti funzionali (FRS).

Un FRD ben scritto descrive ogni flusso di processo per ogni attività, collegando le dipendenze.

FRD contiene i seguenti elementi:

• Scopo del progetto
• ambito del progetto
• Mappa requisiti funzionali
• Ipotesi/vincoli
• Rappresentazione dei requisiti funzionali utilizzando le Informazioni Architettura

Suggerimenti per la Scrittura di un Documento sui Requisiti Funzionali del Modello (FRD)

Creazione di un documento che integra le funzioni tecniche che sono necessarie per l’avvenuta consegna di un software/il prodotto è esattamente come scrivere un messaggio a tutti i coinvolti i membri del team di tecnici attività che si desidera svolgere.

I seguenti suggerimenti vi aiuterà a scrivere un efficace Documento sui Requisiti Funzionali:

• controllare i fatti
• Utilizzare un linguaggio semplice
• Aggiungere le illustrazioni e diagrammi
• Osservare i time frame

Requisiti di Business vs Requisiti Funzionali: Sfide chiave nella Scrittura di un Documento

è una grande sfida per scrivere “bene” o “valido” di business e requisiti funzionali. Le sfide più comuni che si incontrano durante la creazione di questi documenti requisiti includono:

• Una comprensione incompleta del requisito, non riuscendo a chiedere chiarimenti.
• Interpretazione errata del requisito; applicazione di filtri personali alle informazioni che alterano l’intento.
• Scrivere sull’implementazione (il come) invece dei requisiti (il cosa).
• Le decisioni di attuazione dovrebbero essere rinviate il più tardi possibile nel processo di elicitazione dei requisiti.
• Utilizzo della struttura della frase errata.
• Importanza della valutazione della qualità dei requisiti nello sviluppo di prodotti software.

Quali sono i requisiti non funzionali?

I requisiti non funzionali definiscono e specificano il funzionamento del sistema. Tuttavia, non influisce sulla funzionalità del sistema come suggerisce il nome. Quindi, il sistema può continuare a funzionare anche se i suoi requisiti non funzionali non sono soddisfatti. Il motivo per cui i requisiti non funzionali sono essenziali è dovuto alla loro usabilità e poiché aiutano a determinare i fattori che influenzano l’esperienza dell’utente.

Ciò che differenzia i requisiti funzionali e non funzionali è che mentre il primo decide le caratteristiche del prodotto e i requisiti degli utenti, il secondo si concentra sulle proprietà del prodotto e sulle aspettative degli utenti.

Requisiti aziendali vs requisiti funzionali-Conclusione

Dal confronto di cui sopra, è chiaro che i requisiti sono la spina dorsale di ogni azienda. Sia i requisiti aziendali che quelli funzionali costituiscono il fondamento di un’analisi aziendale efficace. I requisiti aziendali spiegano il ” perché “e” cosa “di un progetto e i requisiti funzionali spiegano il” come ” del progetto.

Una revisione periodica e un benchmarking dei requisiti funzionali (sviluppati) con i requisiti aziendali garantiscono il successo complessivo di un progetto. Ecco una dichiarazione conclusiva che ti aiuterà a distinguere chiaramente i requisiti aziendali dai requisiti funzionali: il punto di partenza di qualsiasi analisi aziendale è comprendere i requisiti aziendali (cosa e perché) del cliente e trasformarli in requisiti funzionali (come).