Modelli gratuiti di specifiche funzionali: la roadmap per un'esperienza di sviluppo più fluido

Agile si concentra sulla ricerca del modo più efficiente per fornire un prodotto utile a un utente. Nello sviluppo Agile i documenti e i processi funzionali tradizionali sono talvolta considerati proibitivi dal punto di vista finanziario. Tuttavia acquisire piani e schemi più dettagliati può fare chiarezza.

Uno degli strumenti Agile più comuni sono le user story. Le user story mettono le funzionalità nel contesto di ciò che l'utente deve portare a termine. È possibile raggruppare insieme user story simili per formare epiche Agile. Come per gli elenchi di requisiti funzionali tradizionali, le user story descrivono un'attività o una funzione, ma non il modo in cui gli sviluppatori dovrebbero implementarle.

Le user story utilizzano questa sintassi: "In quanto utente/quando svolgo un'attività voglio avere qualcosa che mi porti dei vantaggi"/ Ecco alcuni esempi:

• Quando guido voglio sapere quando devo sostituire la batteria.
• Quando cucino voglio che lo schermo del tablet resti acceso mentre preparo la ricetta.
• In quanto gatto voglio che mi diano la mia porzione di cibo ogni giorno alle 16:00.

Per testare se una user story è ben formata, si applica l'acronimo INVEST.

• Indipendent (indipendente): la user stpry sta in piedi da sola?
• Negotiable (negoziabile): puoi modificare o rimuovere questa user story senza influire sul resto del progetto?
• Valuable (valida): questa user story ha valore per l'utente finale?
• Estimable (valutabile): puoi stimare la portata della story?
• Small (contenuta): la user story ha dimensioni ragionevoli?
• Testable (testabile): puoi testare questa user story?

Per scopi di gestione dei progetti, nello strumento di tracciamento puoi dare un nome e un ID numerato alle user story. Inoltre puoi assegnare priorità di sviluppo, sprint e stato della storia. Le user story entrano nel backlog di prodotto Agile.

I modelli di user story sono solitamente semplici: si concentrano sull'identificazione del ruolo dell'utente, del suo compito e di ciò che dovrebbe portare a termine l'attività. Inoltre nel modello che segue c'è spazio per le informazioni relative alla storia e al ciclo di sviluppo.

Scarica il modello semplice di user story di Agile

Excel | Word

La pianificazione di un sito web richiede una comprensione ad alto livello della tecnologia necessaria e una comprensione dettagliata di chi utilizzerà il sito e di ciò che tu (titolare del sito) desideri che gli utenti vogliano realizzare. Le user story impiegate nello sviluppo Agile possono aiutarti a concentrarti sulle esigenze degli utenti. Anche altre domande aiutano a contestualizzare il sito web.

Il seguente modello di specifiche per un sito web pone una serie di domande per aiutarti a definire lo scopo del sito, per chi è per il sito, le attività che verranno svolte sul sito ed eventuali considerazioni particolari, come gli standard di sicurezza quali PCI per le transazioni finanziarie.

Scarica il modello di specifiche funzionali per sito web 

Word

Scarica il modello di specifiche tecniche per sito web 

Excel

Quando si sviluppa software e altra tecnologia con il metodo a cascata spesso si può utilizzare un modello di specifiche o requisiti funzionali tradizionale. I requisiti funzionali elencano le caratteristiche e le funzioni di ciò che il prodotto "deve" fare. Ad esempio, "L'aspirapolvere deve raccogliere particelle più piccole di cinque millimetri".

‌ Scarica modelli di specifiche funzionali – Word

Potresti anche preferire un modello con più attenzione ai requisiti aziendali. In questo modello minimalista fornisce c'è spazio per illustrare nel dettaglio lo scopo del prodotto o dell'aggiornamento nel contesto degli obiettivi aziendali, oltre a considerazioni di design di livello superiore.

‌ Scarica il modello di requisiti funzionali – Word

 

È possibile creare casi d'uso per molti tipi di prodotti, tra cui siti web e software. I casi d'uso si concentrano sulle attività che un utente deve svolgere con il prodotto. Concentrandosi sulle attività, i documenti del caso d'uso aiutano a guidare gli sviluppatori verso la creazione di prodotti incentrati sull'utente. Questi documenti evitano anche che gli stakeholder fraintendano il design del prodotto. Usa questo modello di caso d'uso per definire un task in termini di attori, fasi e branch.

Scarica il modello di caso d'uso

Word

Un documento specifiche funzionali (FSD), detto anche documento requisiti funzionali (FRD), è considerato da molti esperti di gestione dei progetti e sviluppo software come la strumento essenziale per evitare di fare confusione e di dare indicazioni sbagliate su un progetto.

Sebbene gli FSD siano spesso associati allo sviluppo software e web, svolgono un ruolo in qualsiasi progetto, dal lancio di un nuovo prodotto a un aggiornamento, dallo sviluppo di un prodotto software o di un oggetto concreto all'introduzione di processi o cambiamenti organizzativi. I documenti specifiche funzionali devono anche soddisfare aspettative aziendali e ingegneristiche. Tutti gli stakeholder esaminano e approvano il documento. Il risultato è un documento di riferimento per il prodotto proposto diretto a tutta l'organizzazione, dagli sviluppatori ai progettisti al personale delle vendite.

È possibile utilizzare un modello di documento specifiche funzionali per assicurarsi di includere tutte le informazioni essenziali di sviluppo. Inoltre i modelli garantiscono che per ogni nuova iniziativa i team si concentrino sui requisiti di prodotto piuttosto che perdere tempo a pensare a come strutturare il documento. I modelli devono essere personalizzati per soddisfare le esigenze specifiche di ciascun team o azienda.

Gli FRD di solito tendono a essere lunghi, aridi e spesso tecnici. Ma documenti così talvolta non sono né necessari né utili. Poiché lo scopo del documento requisiti funzionali è quello di definire l'ambito del progetto per tutti gli stakeholder, gli FRD non si dilungano in discussioni tecniche. Gli FRD possono includere vari tipi di requisiti e informazioni di supporto (vedi elenco seguente), ma la regola d'oro è di descrivere solo le intenzioni di base del documento. Di base il documento deve descrivere il contesto, le caratteristiche e le funzioni da sviluppare. Un documento di progettazione tecnica viene creato in base alle specifiche funzionali accettate. Un FRD non deve essere una copia degli altri documenti su requisiti e processi.

Le specifiche funzionali seguono un processo di approvazione: gli utenti aziendali verificano che la soluzione affronti le loro preoccupazioni e i revisori tecnici verificano che la soluzione descritta possa essere implementata. Spesso tra le figure chiave che si occupano della revisione ci sono tester, utenti finali, technical writer e proprietari di prodotti o sistemi. Il documento è completo quando tutti concordano sui contenuti. Alcune organizzazioni procedono quindi a stilare il documento architettura dei sistemi.

Un documento specifiche funzionali è un riferimento per l'intero team. Mostra ciò che gli sviluppatori di prodotti dovrebbero sviluppare, ciò che i tester dovrebbero testare, ciò che i writer dovrebbero documentare e ciò che il personale di vendita venderà. Delle specifiche funzionali scritte dimostrano che sono state fatte tutte le dovute considerazioni sul design e l'intento prima di iniziare a sviluppare. Dimostra anche che, dopo l'approvazione delle specifiche, tutti gli stakeholder hanno le stesse informazioni. Le specifiche non vanno scritte per compilare il documento dopo che il codice del prodotto è stato scritto.

Alcuni analisti e sviluppatori aziendali distinguono le specifiche funzionali dai requisiti funzionali dicendo che i requisiti dicono cosa il software deve fare mentre le specifiche descrivono il come. In pratica di solito i due ruoli si combinano.

I modelli di documenti specifiche (o requisiti) funzionali possono essere strutturati in vari modi. Il format scelto dipende da ciò che funziona meglio per ciascuna organizzazione.

• Requisiti funzionali: tradizionalmente un documento per software e altre tecnologie che utilizzano il metodo di sviluppo a cascata. I requisiti funzionali elencano le funzioni e le caratteristiche che il prodotto "deve" avere. Ad esempio, "L'aspirapolvere deve raccogliere particelle più piccole di cinque millimetri".
• Casi d'uso: i casi d'uso sono spesso documenti indipendenti. Ma le organizzazioni che valorizzano l'esperienza dell'utente di solito li inseriscono nei requisiti funzionali. I casi di utilizzo inseriscono caratteristiche e funzioni nel contesto delle azioni utente. Ad esempio, "L'utente tocca due volte lo schermo del telefono. Lo schermo si illumina. L'utente scorre il dito sullo schermo verso destra per sbloccare il telefono e le sue funzionalità".
• User story: le user story formano il nucleo dello sviluppo Agile perché descrivono il design del prodotto sotto forma di ciò che l'utente deve fare. Questo approccio succinto aiuta i team a offrire valore agli utenti nel modo più efficiente. Le user story vengono formulate così: "In quanto utente posso fare qualcosa in modo da creare qualche vantaggio".

In genere i business analyst e i tech lead creano modelli e specifiche funzionali che condividono con gli stakeholder aziendali e tecnici i quali li revisionano per garantire che il documento consegnato sia in linea con l'obiettivo.

Le specifiche funzionali si usano nello sviluppo di nuovi software e aggiornamenti. Si possono usare inoltre per apportare modifiche ingegneristiche ai sistemi e all'organizzazione, per lo sviluppo web e altro ancora. Gli utenti delle specifiche includono i seguenti gruppi:

• Sviluppatori, che scrivono il codice del prodotto
• Designer, che creano l'interfaccia utente (UI) per il software, il dispositivo o il sito web
• Tester, che si assicurano che il codice funzioni correttamente e in base alle specifiche
• Marketer, che preparano documenti che stimolano la domanda delle nuova funzionalità
• I team di vendita, che vendono la funzione e il prodotto
• Technical writer o user assistance writer, che documentano come funziona il prodotto per amministratori, utenti finali e altri ruoli

Anche se esistono varie combinazioni e permutazioni di questi documenti, i documenti specifiche funzionali (FSD) e i documenti requisiti aziendali (BRD) sono talvolta separati.

I BRD descrivono i requisiti aziendali di livello superiore di un prodotto (cosa fa). I BRD evitano i dettagli tecnici e forniscono invece nel dettaglio le motivazioni che giustificano un prodotto. Una chiara comprensione di ciò che il prodotto offre e del perché è necessario spesso aiuta a navigare le controversie sulla direzione del prodotto nel percorso di sviluppo. Gli FSD possono concentrarsi sulla definizione delle caratteristiche e della funzionalità del prodotto che devi raggiungere l'obiettivo finale.

Creare un prodotto, sia tangibile che transazionale, può comportare la redazione di molti documenti. I modelli di specifiche funzionali possono essere utilizzati in combinazione con uno qualunque dei documenti seguenti:

• Requisiti utente: questo documento rappresenta ciò che l'utente si aspetta che il prodotto faccia. Alcuni considerano i requisiti utente una parte del documento requisiti funzionali. Se questo documento esiste, andrebbe incluso nel processo di sviluppo complessivo. Nello sviluppo Agile i requisiti dell'utente (espressi come user story) sono considerati il nocciolo dei requisiti funzionali.
• Requisiti del prodotto: utilizzati in modo intercambiabile con i documenti requisiti di mercato, descrivono nel dettaglio lo scopo di un prodotto.
• Documenti processo aziendale: descrivono nel dettaglio un processo aziendale.
• Valutazioni delle esigenze aziendali: descrivono le lacune tra le condizioni attuali e le condizioni aziendali desiderate.
• Specifiche di progettazione tecnica: questo documento descrive (nel più assoluto dettaglio) gli elementi di programmazione necessari per il design proposto.
• Documenti di convalida: i documenti di convalida possono includere una matrice di tracciabilità (che segue le funzionalità durante il processo di sviluppo), piani di test e requisiti operativi.
• Requisiti dei sistemi: questo documento abbozza ad alto livello ciò che ci si aspetta da un sistema o un prodotto.
• Requisiti aziendali: questo documento descrive le ragioni di alto livello per la creazione di un prodotto o un aggiornamento.
• Casi d'uso: forniscono dettagli funzionali e contestualizzano le funzionalità dal punto di vista dell'utente.
• User story: vengono utilizzate principalmente per lo sviluppo Agile. Comunicano l'intento del prodotto descrivendo nel dettaglio ciò che l'utente ci farà.

I requisiti possono essere classificati come funzionali e non funzionali (il cosa e il come).

• Requisito funzionale: descrive un comportamento, un'attività o un risultato che ci si aspetta da un prodotto o un sistema. Ad esempio, "Filtra le particelle dell'acqua" o "Stampa una pagina". I requisiti funzionali comuni includono le funzioni di amministrazione, autorizzazione e autenticazione, il monitoraggio e il reporting degli audit e le regole aziendali.
• Requisito non funzionale: descrive come funziona qualcosa, esprimendo un vincolo, un attributo o un parametro. Se la parola che descrive il processo termina in -ità (in linea di massima) si tratta di un requisito non funzionale. Alcuni esempi sono l'usabilità, la manutenibilità e la sicurezza (eccezione!), oltre alle prestazioni e ai requisiti normativi.

In SAP, un documento specifiche funzionali è una descrizione del prodotto dal punto di vista degli stakeholder, con aspettative precise sul modo in cui la funzione si riferisce a SAP. Combinando i documenti requisiti FSD e requisiti software in uno ottieni le specifiche funzionali.

Come minimo in un FRD non deve mancare:

• A chi è destinato al prodotto
• Chi è autorizzato a utilizzare il prodotto
• Gli input nel sistema
• Cosa dovrebbe fare ogni schermata
• I flussi di lavoro del sistema
• Gli output
• I requisiti normativi cui fa riferimento il prodotto
• I propri requisiti aziendali specifici

Una descrizione scritta delle funzioni desiderate è un elemento essenziale dello sviluppo di un prodotto, ma la forma che assume il modello di requisiti funzionali dipende anche da quello che funziona per il tuo team.

Quando si sviluppa un modello o anche quando si considerano i miglioramenti da apportare a un processo di sviluppo esistente, chiedi a tutti coloro che hanno un forte interesse nel risultato del prodotto cosa vogliono trovare nel modello. Ciascun formato ha vantaggi e svantaggi:

• Usare il verbo "deve" nei requisiti funzionali tradizionali tendono a mancare di contesto e sono più soggette all'interpretazione dello sviluppatore.
• I casi d'uso offrono contesto e dettagli, in cui però possono nascondersi le insidie: man mano che si chiariscono i veri requisiti dell'utente lo scope del progetto può dilatarsi. I requisiti più piccoli possono perdersi tra i casi d'uso.
• Le user story offrono il vantaggio di descrivere le esigenze degli utenti nel contesto dei requisiti aziendali. Ma possono richiedere lavoro extra (ad es. ricerche adeguate). Gli sviluppatori e altri soggetti rischiano di concentrarsi troppo sulle singole user story da escludere il contesto più ampio del prodotto.

Anche in questo caso quando si considera lo strumento da utilizzare per la creazione di documenti di requisiti software, le esigenze della tua organizzazione sono fondamentali. Ciò che funziona per altre aziende potrebbe non funzionare per te.

• Gestione della documentazione: è uno degli strumenti più semplici e trasversali per creare modelli e redigere i documenti. Molti documenti requisiti funzionali sono disponibili sotto forma di modelli di documento.
• Software per fogli di calcolo: i fogli di calcolo consentono di aggiungere colonne a seconda delle necessità. Eliminano anche la pressione del dover comporre frasi perfette perché basta acquisire solo i dettagli essenziali necessari a chi legge per sviluppare il prodotto corretto.
• Piattaforma di gestione dei progetti Agile: molte piattaforme purpose-built offrono funzionalità per acquisire i requisiti o i dettagli della user story e il monitoraggio delle funzioni.

Alcuni requisiti sono essenziali per comunicare l'intento del prodotto, ma altri possono servire o non servire per lo sviluppo del prodotto. Il formato scelto può anche dipendere dal prodotto sviluppato. Ecco un elenco che puoi usare come guida nella preparazione dei requisiti funzionali:

• Fronte

  • Pagina dei metadati: riassume tutto ciò che riguarda il documento.
  • Istruzioni per gli autori: sono particolari informazioni richieste dall'organizzazione in un documento di specifiche. Queste istruzioni possono comparire nell'introduzione o in tutto il modello.
  • Numero di versione
  • Pagina di revisione/registro delle modifiche: nel modello e nel documento requisiti pubblicato dovrebbero comparire tutte le modifiche con i relativi dettagli, le date e le iniziali di chi le ha approvate.
  • Blocco per l'approvazione: ciascuna revisione e ciascun requisito devono essere approvati con una firma.
  • Elenco di distribuzione: può capitare che il documento debba essere rivisto da certi membri del team. In alternativa è possibile impedirne la visualizzazione solo ad alcuni membri del team.

• Panoramica

  • Descrizione del prodotto
  • Panoramica dei requisiti aziendali
  • Ambito di lavoro (cosa sarà coperto e cosa no)
  • Descrizione del sistema attuale
  • Convenzioni del documento
  • Terminologia (compresi gli acronimi)
  • Riferimenti
  • Ipotesi e vincoli generali
     

• Funzionalità

  • Processo aziendale
  • Metodi proposti
  • Ruoli utente/user community
  • Casi d'uso
  • User story
  • Flussi di lavoro all'interno del sistema
  • Prototipi di design
  • Wireframe o storyboard
  • Elenco o descrizioni delle funzioni
  • Dati richiesti
  • Funzionalità di amministrazione
  • Gestione delle configurazioni
  • Piattaforma
  • Installazione
  • Portabilità
  • Espandibilità
  • Personalizzazione
  • Stampa
  • Gestione degli errori
  • Supporto e manutenzione
  • Internazionalizzazione
  • Aiuto e documentazione
     

• Altri software

  • Input, output ed elaborazione
  • Interfacce esterne
  • Interfacce utente
  • Interfacce hardware
  • Interfacce software
  • Interfacce di comunicazione
  • Supporto database
     

• Attributi

  • Sicurezza
  • Affidabilità, disponibilità, manutenzione, usabilità, compatibilità
  • Requisiti normativi
     

• Appendice

  • Modelli di analisi

Potenzia il rendimento dei tuoi dipendenti con una piattaforma flessibile progettata per soddisfare le esigenze del tuo team e capace di adattarsi alle condizioni mutevoli del lavoro. La piattaforma Smartsheet semplifica la pianificazione, l'acquisizione, la gestione e la creazione di report sul lavoro da qualsiasi luogo, aiutando il tuo team a essere più efficace e ottenere di più. Crea report sulle metriche chiave e ottieni visibilità in tempo reale sul lavoro mentre accade con report di riepilogo, pannelli di controllo e flussi di lavoro automatizzati creati per mantenere il tuo team connesso e informato. Quando i team hanno chiarezza sul lavoro da svolgere, possono ottenere maggiori risultati in meno tempo. Prova Smartsheet gratuitamente, oggi.