Tempo di lettura: 9 minuti

I requisiti chiaramente definiti sono segnali essenziali sulla strada che porta a un progetto di successo. Stabiliscono un accordo formale tra un cliente e un fornitore che entrambi stanno lavorando per raggiungere lo stesso obiettivo. Requisiti dettagliati e di alta qualità aiutano anche a mitigare i rischi finanziari e a mantenere il progetto in calendario., Secondo la definizione del corpo di conoscenza dell’analisi aziendale, i requisiti sono una rappresentazione utilizzabile di un bisogno.

La creazione di requisiti è un’attività complessa in quanto include un insieme di processi come l’elicitazione, l’analisi, le specifiche, la convalida e la gestione. In questo articolo, discuteremo i principali tipi di requisiti per i prodotti software e forniremo una serie di raccomandazioni per il loro utilizzo.

Classificazione dei requisiti

Prima di discutere su come vengono creati i requisiti, differenziiamo i loro tipi.,

Requisiti di alto livello cascata fino a dettagli specifici

Requisiti aziendali. Questi includono dichiarazioni di alto livello di obiettivi, obiettivi e bisogni.

Requisiti degli stakeholder. Vengono inoltre specificate le esigenze dei gruppi di stakeholder discreti per definire cosa si aspettano da una particolare soluzione.

Requisiti della soluzione. I requisiti della soluzione descrivono le caratteristiche che un prodotto deve avere per soddisfare le esigenze degli stakeholder e dell’azienda stessa.,

• I requisiti non funzionali descrivono le caratteristiche generali di un sistema. Sono anche conosciuti come attributi di qualità.
• I requisiti funzionali descrivono come un prodotto deve comportarsi, quali sono le sue caratteristiche e funzioni.

Requisiti di transizione. Un ulteriore gruppo di requisiti definisce ciò che è necessario da un’organizzazione per passare con successo dallo stato corrente allo stato desiderato con il nuovo prodotto.

Esploriamo i requisiti funzionali e non funzionali in modo più dettagliato.,

Requisiti funzionali e relative specifiche

I requisiti funzionali sono caratteristiche o funzioni del prodotto che gli sviluppatori devono implementare per consentire agli utenti di svolgere le proprie attività. Quindi, è importante renderli chiari sia per il team di sviluppo che per gli stakeholder. Generalmente, i requisiti funzionali descrivono il comportamento del sistema in condizioni specifiche. Ad esempio:

Una funzione di ricerca consente a un utente di cercare tra varie fatture se desidera accreditare una fattura emessa.

Ecco un altro semplice esempio: come ospite, voglio un divano su cui posso dormire durante la notte.,

I requisiti sono di solito scritti in testo, specialmente per progetti Agili. Tuttavia, possono anche essere immagini. Qui sono i formati più comuni e documenti:

• Software specifica dei requisiti di documento
• i casi d’Uso
• le storie Utente
• Work Breakdown Structure (WBS) (decomposizione funzionale)
• Prototipi
• Modelli e diagrammi

Software specifica dei requisiti di documento

Funzionali e non funzionali requisiti può essere formalizzato nella specifica dei requisiti (SRS) del documento., (Per saperne di più sulla documentazione del software, leggi il nostro articolo su questo argomento.) L’SRS contiene descrizioni delle funzioni e delle capacità che il prodotto deve fornire. Il documento definisce anche vincoli e ipotesi. L’SRS può essere un singolo documento che comunica i requisiti funzionali o può accompagnare altra documentazione software come storie utente e casi d’uso.

Non è consigliabile comporre SRS per l’intera soluzione prima del calcio d’inizio dello sviluppo, ma è necessario documentare i requisiti per ogni singola funzionalità prima di crearla effettivamente., Una volta ricevuto il feedback iniziale dell’utente, è possibile aggiornare il documento.

SRS deve includere le seguenti sezioni:

Scopo. Definizioni, panoramica del sistema e sfondo.

Descrizione generale. Presupposti, vincoli, regole aziendali e visione del prodotto.

Requisiti specifici. Attributi di sistema, requisiti funzionali, requisiti di database.

È essenziale rendere l’SRS leggibile per tutte le parti interessate. Dovresti anche usare modelli con enfasi visiva per strutturare le informazioni e aiutare a comprenderle., Se i requisiti sono memorizzati in altri formati di documento, collegarli per consentire ai lettori di trovare le informazioni necessarie.

Esempio: Se desideri vedere un documento reale, scarica questo esempio SRS creato presso la Michigan State University, che include tutti i punti sopra menzionati oltre a presentare casi d’uso per illustrare parti del prodotto.

Casi d’uso

I casi d’uso descrivono l’interazione tra il sistema e gli utenti esterni che porta al raggiungimento di determinati obiettivi.

Ogni caso d’uso include tre elementi principali:

Attori., Questi sono gli utenti esterni al sistema che interagiscono con il sistema.

Sistema. Il sistema è descritto da requisiti funzionali che definiscono un comportamento previsto del prodotto.

Obiettivi. Gli scopi dell’interazione tra gli utenti e il sistema sono delineati come obiettivi.

Esistono due formati per rappresentare i casi d’uso:

• Specifica del caso d’uso strutturata in formato testuale
• Diagramma del caso d’uso

Una specifica del caso d’uso rappresenta la sequenza di eventi insieme ad altre informazioni relative a questo caso d’uso., Un tipico caso d’uso specifica del modello include le seguenti informazioni:

• Descrizione
• Pre – e Post – interazione condizioni
• interazione di Base percorso
• percorso Alternativo
• percorso Eccezione

Esempio:

caso d’Uso specifica del modello

Un diagramma caso di utilizzo non contengono un sacco di dettagli. Mostra una panoramica di alto livello delle relazioni tra attori, diversi casi d’uso e il sistema.

Il diagramma dei casi d’uso include i seguenti elementi principali:

Casi d’uso., Solitamente disegnati con ovali, i casi d’uso rappresentano diversi scenari di utilizzo che gli attori potrebbero avere con il sistema (accedere, effettuare un acquisto, visualizzare elementi, ecc.)

Limiti di sistema. I limiti sono delineati dalla casella che raggruppa vari casi d’uso in un sistema.

Attori. Queste sono le figure che raffigurano utenti esterni (persone o sistemi) che interagiscono con il sistema.

Associazioni. Le associazioni sono disegnate con linee che mostrano diversi tipi di relazioni tra attori e casi d’uso.,

Esempio:

Esempio del diagramma dei casi d’uso

User story

Una user story è una descrizione documentata di una funzionalità software vista dal punto di vista dell’utente finale. La storia utente descrive cosa esattamente l’utente vuole che il sistema faccia. Nei progetti Agile, le storie degli utenti sono organizzate in un backlog, che è un elenco ordinato di funzioni del prodotto. Attualmente, le storie degli utenti sono considerate il formato migliore per gli elementi del backlog.,

Un utente tipico storia è scritta come questa:

nel <tipo di utente> Voglio <qualche obiettivo> tale <qualche ragione>.

Esempio:

Come amministratore, voglio aggiungere descrizioni ai prodotti in modo che gli utenti possano visualizzare in seguito queste descrizioni e confrontare i prodotti.

Le storie degli utenti devono essere accompagnate da criteri di accettazione., Queste sono le condizioni che il prodotto deve soddisfare per essere accettato da un utente, stakeholder o proprietario di un prodotto. Ogni storia utente deve avere almeno un criterio di accettazione. I criteri di accettazione efficaci devono essere verificabili, concisi e completamente compresi da tutti i membri del team e dalle parti interessate. Possono essere scritti come liste di controllo, testo normale o utilizzando il formato dato/Quando/Allora.

Esempio:

Ecco un esempio della lista di controllo dei criteri di accettazione per una storia utente che descrive una funzione di ricerca:

• Un campo di ricerca è disponibile nella barra superiore.,
• Una ricerca viene avviata quando l’utente fa clic su Invia.
• Il segnaposto predefinito è un testo grigio Digitare il nome.
• Il segnaposto scompare quando l’utente inizia a digitare.
• La lingua di ricerca è l’inglese.
• L’utente può digitare non più di 200 simboli.
• Non supporta simboli speciali. Se l’utente ha digitato un simbolo speciale nell’input di ricerca, viene visualizzato l’avviso massaggio: l’input di ricerca non può contenere simboli speciali.,

Infine, tutte le storie utente devono adattarsi al modello di qualità INVEST:

• I – Indipendente
• N – Negoziabile
• V – Prezioso
• E – Stimabile
• S – Piccolo
• T – testabile

Indipendente. Ciò significa che è possibile pianificare e implementare ogni storia utente separatamente. Questo è molto utile se si implementano processi di integrazione continua.

Negoziabile. Ciò significa che tutte le parti concordano di dare priorità ai negoziati rispetto alle specifiche. Ciò significa anche che i dettagli verranno creati costantemente durante lo sviluppo.

Prezioso., Una storia deve essere preziosa per il cliente. Dovresti chiederti dal punto di vista del cliente “perché” è necessario implementare una determinata funzionalità.

Stimabile. Una storia utente di qualità può essere stimata. Ciò aiuterà un team a pianificare e dare priorità all’implementazione. Più grande è la storia, più difficile è stimarla.

Piccolo. Le buone storie degli utenti tendono ad essere abbastanza piccole da pianificare brevi rilasci di produzione. Piccole storie consentono stime più specifiche.

verificabile. Se una storia può essere testata, è abbastanza chiara e abbastanza buona., Storie testate significano che i requisiti sono fatti e pronti per l’uso.

Functional Decomposition or Work Breakdown Structures (WBS)

Una decomposizione funzionale o WBS è un documento visivo che illustra come i processi complessi si scompongono nei loro componenti più semplici. WBS è un approccio efficace per consentire un’analisi indipendente di ogni parte. WBS aiuta anche a catturare il quadro completo del progetto.

Suggeriamo la seguente logica di decomposizione funzionale:

1. Trova la funzione più generale.
2. Trova la funzione secondaria più vicina.,
3. Trova il livello successivo della funzione secondaria.
4. Controlla il tuo diagramma.

O il processo di decomposizione può assomigliare a questo:

Funzione ad Alto Livello ->Sub-funzione -> Processo> Attività

Le caratteristiche dovrebbero essere scomposto per il punto in cui il livello più basso di parti non può essere suddiviso ulteriormente.,

Esempio:

un esempio di decomposizione funzionale

prototipi Software

prototipo Software è un termine ombrello per le diverse forme di early stage risultati che sono costruiti per mostrare come i requisiti devono essere implementati. I prototipi aiutano a colmare le lacune della visione e consentono alle parti interessate e ai team di chiarire aree complicate dei prodotti in fase di sviluppo. Tradizionalmente, i prototipi rappresentano come funzionerà la soluzione e forniscono esempi di come gli utenti interagiranno con essa per svolgere i loro compiti.,

I prototipi possono essere rappresentazioni visive economiche e veloci di requisiti (prototipi usa e getta) o più complessi (prototipi evolutivi). Quest’ultimo può anche diventare le prime versioni del prodotto che hanno già alcuni pezzi del codice finale. In effetti, i prototipi evolutivi possono persino trasformarsi in MVP che abbiamo descritto in un articolo separato.

Documenti di progettazione e prototipi

I requisiti di progettazione vengono solitamente raccolti e documentati utilizzando tre formati principali che si trasformano l’uno nell’altro:

Wireframe., I wireframe sono strutture grafiche a bassa fedeltà di un sito web o di un’app. Aiutano a mappare diverse pagine di prodotto con sezioni ed elementi interattivi.

Modelli. Una volta che i wireframe sono pronti, vengono trasformati in mockup, design visivi che trasmettono l’aspetto del prodotto finale. Alla fine, i mockup possono diventare il design finale del prodotto.

Prototipi di progettazione. Questi documenti contengono elementi visivi e consentono alcune interazioni di interfaccia, come lo scorrimento, facendo clic sui link o compilando moduli., I prototipi di progettazione possono essere creati da zero utilizzando HTML e CSS, ma la maggior parte dei team UX utilizza servizi di prototipazione come InVision.

Esempio:

Per ulteriori informazioni su come vengono gestiti i processi di progettazione UX, consulta il nostro caso di studio sulla creazione di una soluzione di gestione dei viaggi per Cornerstone, un fornitore SaaS aziendale, in cui abbiamo utilizzato tutti e tre i tipi di requisiti di progettazione.

Requisiti non funzionali

Requisiti non funzionali descrivono come un sistema deve comportarsi e stabilire vincoli della sua funzionalità. Questo tipo di requisiti è noto anche come attributi di qualità del sistema.,

Diamo un’occhiata da vicino ai tipici requisiti non funzionali.

Usabilità

Usabilità definisce quanto sia difficile per un utente imparare e far funzionare il sistema. L’usabilità può essere valutata da diversi punti di vista:

Efficienza di utilizzo: il tempo medio necessario per raggiungere gli obiettivi di un utente, quante attività un utente può completare senza alcun aiuto, il numero di transazioni completate senza errori, ecc.

Intuitività: quanto è semplice capire l’interfaccia, i pulsanti, le intestazioni, ecc.,

Carico di lavoro percepito basso: quanti tentativi sono necessari agli utenti per eseguire una particolare attività.

Esempio: I requisiti di usabilità possono considerare le barriere linguistiche e le attività di localizzazione: le persone senza comprensione del francese devono essere in grado di utilizzare il prodotto. Oppure è possibile impostare i requisiti di accessibilità: gli utenti della tastiera che navigano in un sito web utilizzando <tab>, devono essere in grado di raggiungere il pulsante “Aggiungi al carrello” da una pagina del prodotto entro 15 <tab> clic.,

Sicurezza

I requisiti di sicurezza assicurano che il software sia protetto dall’accesso non autorizzato al sistema e ai suoi dati memorizzati. Considera diversi livelli di autorizzazione e autenticazione tra diversi ruoli degli utenti. Ad esempio, la privacy dei dati è una caratteristica di sicurezza che descrive chi può creare, vedere, copiare, modificare o eliminare le informazioni. La sicurezza include anche la protezione contro virus e attacchi malware.

Esempio: le autorizzazioni di accesso per le particolari informazioni di sistema possono essere modificate solo dall’amministratore dei dati del sistema.,

Affidabilità

L’affidabilità definisce la probabilità che il software funzioni senza guasti per un determinato periodo di tempo. L’affidabilità diminuisce a causa di bug nel codice, guasti hardware o problemi con altri componenti del sistema. Per misurare l’affidabilità del software, è possibile contare la percentuale di operazioni completate correttamente o tenere traccia del periodo di tempo medio in cui il sistema viene eseguito prima di fallire.

Esempio: il processo di aggiornamento del database deve eseguire il rollback di tutti gli aggiornamenti correlati quando un aggiornamento non riesce.,

Prestazioni

Le prestazioni sono un attributo di qualità che descrive la reattività del sistema alle varie interazioni dell’utente con esso. Le scarse prestazioni portano a un’esperienza utente negativa. Inoltre mette a repentaglio la sicurezza del sistema quando è sovraccarico.

Esempio: Il tempo di caricamento della prima pagina non deve essere superiore a 2 secondi per gli utenti che accedono al sito web utilizzando una connessione mobile LTE.

Disponibilità

La disponibilità viene misurata in base al periodo di tempo in cui le funzionalità e i servizi del sistema sono disponibili per l’uso con tutte le operazioni., Pertanto, i periodi di manutenzione pianificati influenzano direttamente questo parametro. Ed è importante definire come l’impatto della manutenzione può essere ridotto al minimo. Quando si scrivono i requisiti di disponibilità, il team deve definire i componenti più critici del sistema che devono essere sempre disponibili. Dovresti anche preparare le notifiche utente nel caso in cui il sistema o una delle sue parti non sia disponibile.

Esempio: la distribuzione del nuovo modulo non deve influire sulla prima pagina, sulle pagine dei prodotti e sulla disponibilità delle pagine di controllo e non deve richiedere più di un’ora., Il resto delle pagine che potrebbero avere problemi deve visualizzare una notifica con un timer che mostra quando il sistema sta per essere di nuovo.

Scalabilità

I requisiti di scalabilità descrivono come il sistema deve crescere senza influire negativamente sulle sue prestazioni. Ciò significa servire più utenti, elaborare più dati e fare più transazioni. La scalabilità ha implicazioni sia hardware che software. Ad esempio, è possibile aumentare la scalabilità aggiungendo memoria, server o spazio su disco. D’altra parte, è possibile comprimere i dati, utilizzare algoritmi di ottimizzazione, ecc.,

Esempio: il limite di partecipazione al sito web deve essere abbastanza scalabile da supportare 200.000 utenti alla volta.

Parole finali

Tutti i progetti software includono i confini informativi che descrivono il prodotto e gli obiettivi del progetto. Questi confini sono disegnati nei requisiti e nelle specifiche del progetto. Il valore della creazione di specifiche dei requisiti software è nell’ottimizzazione del processo di sviluppo. Le specifiche dei requisiti del software rispondono a tutte le domande degli sviluppatori sul prodotto necessarie per iniziare il lavoro., La specifica funzionale è approvata dal cliente e garantisce che gli sviluppatori stiano costruendo ciò che il cliente desidera.