Cos'è un requisito funzionale nell'ingegneria del software?

By: charles moore charles moore
Hours aggiornato

⚡ Riepilogo intelligente

I requisiti funzionali descrivono ogni servizio che un sistema software deve offrire, specificando input, comportamento e output, in modo che sviluppatori, tester e stakeholder aziendali condividano un'unica definizione verificabile di ciò che il prodotto deve effettivamente fare.

  • 📘 Definizione: Un requisito funzionale, detto anche specifica funzionale, definisce cosa deve fare il sistema: input, comportamento e output, descritti dal punto di vista dell'utente o dell'azienda.
  • 📄 Ambito del documento: Un documento sui requisiti funzionali (FRD) descrive le operazioni a schermo, la logica di gestione dei dati, i report, i flussi di lavoro, le autorizzazioni e la conformità normativa.
  • 🗂️ Tipi comuni: Gestione delle transazioni, regole aziendali, reporting, funzioni amministrative, livelli di autorizzazione, audit tracre, interfacce esterne e requisiti legali.
  • 💡 Esempi: La convalida dell'accesso, la registrazione delle vendite, la visualizzazione dei ricavi in ​​base ai ruoli, l'integrazione con le API bancarie e la conformità all'accessibilità sono tutti requisiti funzionali.
  • 🆚 Contrasto non funzionale: I requisiti funzionali descrivono cosa fa un sistema; i requisiti non funzionali descrivono quanto bene lo fa, ovvero in termini di prestazioni, sicurezza e usabilità.
  • ✅ migliori pratiche: Definisci i requisiti in modo dettagliato, verificabile e allineato a un obiettivo aziendale, e raccoglili attraverso interviste e workshop.
Scopri di più

Requisiti funzionali nell'ingegneria del software

Cos'è un requisito funzionale?

A Requisito funzionale (FR) è una descrizione del servizio che il software deve offrire. Descrive un sistema software o un suo componente. Una funzione è definita da input, comportamento e output. Può essere un calcolo, una manipolazione di dati, un processo aziendale o un'interazione con l'utente che definisce cosa deve fare il sistema. I requisiti funzionali nell'ingegneria del software sono anche chiamati Specificazioni funzionali.

Un requisito funzionale può variare da un'esigenza di alto livello degli stakeholder a una specifica matematica dettagliata. Software funzionale I requisiti descrivono il comportamento previsto del sistema.

Cosa includere in un documento dei requisiti funzionali

Ecco cosa dovrebbe includere un documento sui requisiti funzionali:

Requisiti funzionali di esempio

Requisiti funzionali di esempio

Un documento sui requisiti funzionali in genere include:

  • Dettagli delle operazioni eseguite su ogni schermata
  • logica di gestione dei dati che il sistema deve applicare
  • Descriptioni di report di sistema e altri output
  • Informazioni complete sui flussi di lavoro eseguiti dal sistema
  • Chi è autorizzato a creare, modificare o eliminare dati nel sistema?
  • Come il sistema soddisfa i requisiti normativi e di conformità applicabili

Vantaggi dei requisiti funzionali

I principali vantaggi di un documento di requisiti funzionali ben redatto sono:

  • Verifica che l'applicazione fornisca tutte le funzioni specificate
  • Definisce in un unico punto la funzionalità del sistema e dei suoi sottosistemi.
  • Insieme all'analisi dei requisiti, i requisiti funzionali aiutano a identificare le esigenze mancanti e a chiarire il comportamento previsto del sistema.
  • Gli errori individuati nella fase di definizione dei requisiti sono i più economici da correggere.
  • Supporta gli obiettivi, i compiti e le attività dell'utente.

Tipi di requisiti funzionali

Le categorie comuni di requisiti funzionali includono:

  • Gestione delle transazioni
  • Regole aziendali
  • Requisiti di certificazione
  • Requisiti di segnalazione
  • Funzioni amministrative
  • Livelli di autorizzazione
  • Audit Tracking
  • Interfacce esterne
  • Gestione dei dati storici
  • Requisiti legali e normativi

ARTICOLI CORRELATI

Esempi di requisiti funzionali

Di seguito sono riportati alcuni esempi pratici di requisiti funzionali:

  • Il software dovrà convalidare automaticamente i clienti rispetto al sistema di gestione dei contatti ABC.
  • Il sistema di vendita deve consentire agli utenti di registrare le vendite ai clienti.
  • Il colore di sfondo di tutte le finestre dell'applicazione deve essere blu con valore RGB esadecimale 0x0000FF.
  • Solo i dipendenti con funzioni dirigenziali avranno il diritto di visualizzare i dati relativi ai ricavi.
  • Il sistema software dovrà integrarsi con l'API bancaria.
  • Il sistema software deve soddisfare Unità 508 requisiti di accessibilità.

Requisiti funzionali vs. non funzionali

Ecco le principali differenze tra requisiti funzionali e non funzionali in Software Engineering:

Scheda Sintetica Requisito funzionale Requisito non funzionale
Cos'è Verbo Attributi
Requisito È obbligatorio Non è obbligatorio
Tipo di cattura Viene acquisito nel caso d'uso. Viene catturato come attributo di qualità.
Risultato finale caratteristica di prodotto Proprietà del prodotto
Catturare Facile da catturare Difficile da catturare
Obiettivo Aiuta a verificare la funzionalità del software. Ti aiuta a verificare le prestazioni del software.
Area di interesse Concentrarsi sulle esigenze dell'utente Si concentra sulle aspettative dell'utente.
Documentazione Descrivi cosa fa il prodotto Descrive come funziona il prodotto
Tipo di test Test funzionali come sistema, integrazione, end to end, Test dell'API, ecc. Test non funzionali come prestazioni, stress, usabilità, Test di sicurezza, ecc.
Esecuzione del test L'esecuzione dei test viene effettuata prima dei test non funzionali. Dopo il test funzionale
Informazioni sul prodotto Caratteristiche Proprietà del prodotto

Migliori pratiche per la scrittura dei requisiti funzionali

Le migliori pratiche più importanti per la stesura di un Documento dei Requisiti Funzionali sono:

  • Non unire due requisiti in uno solo; mantieni ogni requisito distinto.
  • Fornite ogni requisito nel modo più completo e accurato possibile.
  • Redigere nel documento tutti i requisiti tecnici.
  • Mappare ogni requisito rispetto agli obiettivi e ai principi che guidano la realizzazione di software di successo.
  • Raccogli i requisiti attraverso interviste, workshop e conversazioni informali.
  • Documentare ogni vincolo noto e verificato che influisce in modo sostanziale su un requisito.
  • Annota ogni ipotesi nel documento.

Errori comuni nella stesura dei requisiti funzionali

Gli errori più comuni commessi durante la creazione di un documento sui requisiti funzionali includono:

  • Aggiungere informazioni extra non giustificate che confondono gli sviluppatori
  • Omettendo i dettagli necessari agli sviluppatori per realizzare la funzionalità.
  • Regole di miscelazione, esempi, scoping dichiarazioni o obiettivi nei requisiti stessi.
  • Omettere informazioni essenziali per definire il requisito in modo completo e accurato.
  • Difendere un requisito esistente quando arriva una richiesta di modifica, invece di trovare la risposta corretta.
  • Requisiti di scrittura che non sono correlati ad alcun obiettivo o principio.

DOMANDE FREQUENTI

Gli strumenti di intelligenza artificiale raggruppano gli appunti delle interviste, generano bozze di user story, segnalano il linguaggio ambiguo e rilevano i duplicati in grandi insiemi di requisiti. Gli analisti aziendali, tuttavia, convalidano ogni suggerimento confrontandolo con le reali esigenze degli stakeholder prima che venga incluso nella baseline approvata.

Copilot e GPT producono bozze di user story, criteri di accettazione e dichiarazioni di conformità a partire da brevi indicazioni. Un analista aziendale revisiona ogni output per verificarne la testabilità e conferma la coerenza con gli obiettivi aziendali prima della revisione formale.

Un requisito aziendale definisce il motivo per cui un progetto esiste, ad esempio la crescita del fatturato o la conformità normativa. Un requisito funzionale definisce cosa il sistema deve fare per raggiungere tale risultato, come convalidare un pagamento o generare un report.

Utilizza un soggetto chiaro, il verbo "dovere" e un'azione verificabile per ogni affermazione. Evita parole ambigue come "veloce" e descrivi un solo comportamento in modo che il requisito possa essere verificato con un singolo controllo di successo o fallimento.

EARS, Easy Approach to Requirements Syntax, fornisce cinque modelli: ubiquitous, event-driven, state-driven, optional feature e unwanted behaviour. Ciascuno impone una struttura testabile come ad esempio Quando TRIGGER il sistema deve RISPONDERE.

Una specifica dei requisiti software è il documento principale che descrive cosa deve fare un sistema. I requisiti funzionali costituiscono la sezione più ampia, insieme alle interfacce, ai requisiti non funzionali, ai casi d'uso e ai vincoli.

I requisiti funzionali guidano i casi di test nei test di sistema, di integrazione, end-to-end, API e di accettazione da parte dell'utente. Ogni requisito corrisponde ad almeno un caso di test e i requisiti TracLa matrice di idoneità conferma la copertura prima del rilascio.

I team Agile esprimono i requisiti funzionali come user story utilizzando il formato "Come ruolo, desidero una capacità, in modo che abbia valore". I criteri di accettazione allegati alla storia trasformano il requisito in una definizione verificabile di fatto.

Riassumi questo post con: