Analisi dei requisiti software con esempi
charles moore
⚡ Riepilogo intelligente
L'analisi dei requisiti software scompone le esigenze degli stakeholder in dichiarazioni funzionali e non funzionali, le classifica a livello aziendale, architettonico e di sistema, quindi controlla ciascuna di esse rispetto agli attributi di qualità per garantire un testabile, tracSpecifiche chiare e prioritarie.
Un requisito software è un'esigenza funzionale o non funzionale che deve essere implementata nel sistema. Funzionale significa fornire un servizio specifico all'utente.
Ad esempio, nel contesto di un'applicazione bancaria, il requisito funzionale è che quando un cliente seleziona "Visualizza saldo" dovrebbe essere in grado di visualizzare il saldo più recente del proprio conto.
Un requisito software può anche essere non funzionale, come ad esempio un requisito di prestazioni. Ad esempio, un requisito non funzionale potrebbe stabilire che ogni pagina del sistema debba caricarsi per gli utenti entro 5 secondi.
Quindi in poche parole requisito software è a
- Funzionale o
- Non funzionale
bisogno che deve essere implementato nel sistema. I requisiti software sono generalmente espressi sotto forma di dichiarazioni.
Tipi di requisiti
Requisiti aziendaliQuesti sono requisiti di alto livello tratti dal business case del progetto. Ad esempio, un sistema di mobile banking fornisce servizi bancari al Sud-est asiatico. Il requisito aziendale stabilito per l'India è il riepilogo del conto e il trasferimento di fondi, mentre per la Cina è il riepilogo del conto e il pagamento delle bollette.
| Paese | Società che fornisce Funzionalità o servizi bancari |
|---|---|
| India | Riepilogo conto e trasferimento fondi |
| Cina | Riepilogo del conto e Bill Pagamento |
Archirequisiti strutturali e di progettazioneQuesti requisiti sono più dettagliati dei requisiti aziendali e guidano l'architettura della soluzione. Determinano la progettazione complessiva necessaria per implementare il requisito aziendale. Per un'organizzazione educativa, i casi d'uso tipici di architettura e progettazione includono l'accesso, i dettagli del corso e l'iscrizione. Il requisito sarebbe come mostrato di seguito.
| Caso d'uso bancario | Requisito |
|---|---|
| Bill Pagamento | Questo caso d'uso descrive come un cliente può accedere al net banking e utilizzare il servizio Bill Sistema di pagamento. Il cliente può visualizzare una dashboard con le fatture in sospeso per i fornitori registrati. Il cliente può aggiungere, modificare ed eliminare i dettagli di un fornitore. Il cliente può configurare avvisi via SMS ed e-mail per diverse azioni di fatturazione. Il cliente può visualizzare la cronologia delle fatture pagate in passato. Gli attori che avviano questo caso d'uso sono i clienti della banca o il personale di supporto. |
Requisiti di sistema e integrazioneAl livello più basso, abbiamo i requisiti di sistema e di integrazione. Forniscono una descrizione dettagliata di ogni requisito. Possono essere rappresentati come user story scritte nel linguaggio aziendale di tutti i giorni. I requisiti contengono molti dettagli in modo che gli sviluppatori possano iniziare a programmare. Bill L'esempio del modulo di pagamento riportato di seguito mostra i requisiti per l'aggiunta di un fornitore di servizi di pagamento.
| Bill Pagamento | Requisiti |
|---|---|
| Aggiungi BillERS | Nome del fornitore di servizi, Numero cliente, Pagamenti automatici – Sì/No, Paga per intero Bill – Sì/No, limite di pagamento automatico – Non pagare se Bill è superiore all'importo specificato |
A volte, per un progetto, potresti non ricevere requisiti o documenti su cui basarti. Anche in questi casi, esistono altre fonti di informazioni sui requisiti a cui puoi fare riferimento per la progettazione del software o dei test. Le altre fonti di requisiti a cui puoi fare riferimento sono elencate di seguito.
Altre fonti di requisiti
- Trasferimento di conoscenze da colleghi o dipendenti che stanno già lavorando a quel progetto
- Discuti il progetto con l'analista aziendale, il responsabile del prodotto, il responsabile del progetto e gli sviluppatori.
- Analizzare la versione precedente del sistema già implementato
- Analizzare i documenti dei requisiti più vecchi del progetto
- RevConsulta le segnalazioni di bug precedenti; alcune segnalazioni di bug vengono convertite in richieste di miglioramento che potrebbero essere implementate nella versione corrente.
- Consultare la guida all'installazione, se disponibile, per verificare quali installazioni sono necessarie.
- Analizzare le conoscenze di dominio o di settore che il team sta cercando di implementare
Qualunque sia la fonte dei requisiti che utilizzi, documentali in un formato condiviso e falli rivedere da membri esperti del team.
Come analizzare i requisiti
Consideriamo l'esempio di un sistema software didattico in cui uno studente può iscriversi a diversi corsi.
Analizziamo come interpretare i requisiti. Ciascun requisito deve rispettare una serie di attributi di qualità standard, tra cui i seguenti:
- Atomic
- Identificato in modo univoco
- Completato
- Coerente e inequivocabile
- Traccommestibile
- Prioritized
- Testabile
La tabella seguente illustra ciascun attributo con tre colonne:
- La prima colonna indica- "qualità del requisito"
- La seconda colonna indica: "cattivo requisito con qualche problema"
- La terza colonna mostra lo stesso requisito "convertito in un buon requisito".
| Requisiti Qualità | Esempio di cattivo requisito | Esempio di buon requisito |
|---|---|---|
| Atomic | Gli studenti potranno immatricolarsi ai corsi di laurea e post laurea | Gli studenti potranno iscriversi a corsi di laurea triennale. Gli studenti potranno iscriversi a corsi di laurea magistrale. |
| Identificato in modo univoco | 1- Gli studenti potranno iscriversi a corsi di laurea triennale. 1- Gli studenti potranno iscriversi a corsi di laurea magistrale. | Iscrizione ai corsi. Gli studenti potranno iscriversi ai corsi di laurea triennale. Gli studenti potranno iscriversi ai corsi di laurea magistrale. |
| Completato | Un utente professore accederà al sistema fornendo nome utente, password e altre informazioni pertinenti | Un utente professore accederà al sistema fornendo nome utente, password e codice dipartimento |
| Coerente e inequivocabile | Uno studente avrà corsi di laurea o corsi post-laurea, ma non entrambi. Alcuni corsi saranno aperti sia a studenti universitari che post-laurea | Uno studente avrà laurea o post-laurea, ma non entrambi |
| Traccommestibile | Mantenere le informazioni sugli studenti mappate su BRD req.ID? | Mantieni le informazioni sugli studenti: mappato all'ID richiesta BRD 4.1 |
| Prioritized | Studente registrato - Priorità 1. Gestisci le informazioni utente - Priorità 1. Iscriviti ai corsi - Priorità 1. Visualizza la pagella - Priorità 1 | Registra studente - Priorità 1. Gestisci informazioni utente - Priorità 2. Iscrivi corsi - Priorità 1. Visualizza pagella - Priorità 3 |
| Testabile | Ogni pagina del sistema verrà caricata in un lasso di tempo accettabile | Le pagine del sistema di registrazione degli studenti e di iscrizione ai corsi verranno caricate entro 5 secondi |
Cerchiamo di comprendere ciascuno di questi attributi più nel dettaglio, iniziando da Atomcircuito integrato.
Atomic
Ogni requisito deve essere atomico, ovvero deve essere al livello di dettaglio più basso e non può essere ulteriormente scomposto in componenti. Gli esempi seguenti confrontano requisiti atomici e non atomici.
Continuando con l'esempio del sistema del dominio dell'istruzione: in questo caso, il requisito errato è "Gli studenti potranno iscriversi a corsi di laurea triennale e magistrale". Questo è un requisito errato perché non è atomico, in quanto mescola due entità diverse, i corsi di laurea triennale e i corsi di laurea magistrale. Il requisito corretto corrispondente lo separa in due requisiti distinti. Un requisito riguarda l'iscrizione ai corsi di laurea triennale e l'altro l'iscrizione ai corsi di laurea magistrale.
Identificato in modo univoco
Il prossimo attributo di qualità è l'identificazione univoca. Nell'esempio negativo, due requisiti distinti condividono lo stesso ID n. 1. Se un team fa riferimento a un requisito tramite il suo ID, non è chiaro a quale dei due ci si riferisca. Un buon requisito li raggruppa nella Sezione 1 - Iscrizione ai corsi, con i sottorequisiti 1.1 (iscrizione ai corsi di laurea triennale) e 1.2 (iscrizione ai corsi di laurea magistrale).
Completato
Ogni requisito deve essere completo. Ad esempio, in questo caso il requisito errato afferma che "l'utente professore accederà al sistema fornendo il proprio nome utente, password e altre informazioni pertinenti". L'espressione "altre informazioni pertinenti" è vaga. Un requisito completo elenca i campi esatti, come il codice del dipartimento, che il professore deve fornire.
Coerente e inequivocabile
Ogni requisito deve essere coerente e inequivocabile. Nell'esempio negativo, un requisito afferma "Uno studente potrà frequentare corsi di laurea triennale o corsi di laurea magistrale, ma non entrambi", mentre un altro afferma "Alcuni corsi saranno aperti sia agli studenti di laurea triennale che a quelli di laurea magistrale".
Il primo requisito implica che i corsi siano suddivisi in due categorie esclusive, ma il secondo requisito lo contraddice, aprendo alcuni corsi a entrambi i gruppi.
Il requisito corretto risolve il conflitto stabilendo chiaramente che ogni corso è classificato come di laurea triennale o magistrale, e che uno studente può iscriversi solo a corsi di una delle due categorie.
Traccommestibile
Ogni requisito deve essere tracrealizzabile perché i requisiti esistono a più livelli: aziendale, architettonico e di progettazione, e di sistema e integrazione.
Quando si converte un requisito aziendale in requisiti architettonici e di progettazione, o i requisiti architettonici e di progettazione in requisiti di sistema e di integrazione, tracLa fruibilità deve essere preservata. Ogni requisito aziendale dovrebbe corrispondere a uno o più requisiti architetturali e di progettazione. Nell'esempio errato "Gestisci le informazioni sugli studenti - mappato all'ID del requisito BRD?", manca l'ID del requisito.
Il requisito corretto registra la stessa dichiarazione ma mappa esplicitamente al requisito BRD ID 4.1. Ogni requisito deve essere accompagnato da un tracmappa dell'accessibilitàpingI requisiti di sistema e di integrazione devono inoltre essere mappati al codice che li implementa e ai casi di test che li verificano.
TracLa facilità d'uso è quindi un aspetto che permea l'intero progetto.
Prioritized
Ogni requisito deve essere prioritarizzato in modo che il team sappia cosa implementare per primo e cosa può aspettare. Nell'esempio negativo, Registrazione studente, Gestione informazioni utente, Iscrizione ai corsi e Visualizzazione pagella sono tutti impostati come priorità 1. Non tutto può avere priorità 1, quindi i requisiti devono essere classificati in modo realistico. Nell'esempio positivo, Registrazione studente e Iscrizione ai corsi hanno la priorità più alta (1), Gestione informazioni utente (2) e Visualizzazione pagella (3).
Testabile
Ogni requisito dovrebbe essere testabile. L'esempio negativo, "ogni pagina del sistema si caricherà in un lasso di tempo accettabile", non è testabile per due motivi. In primo luogo, "ogni pagina" può significare decine di pagine, il che aumenta esponenzialmente lo sforzo di test. In secondo luogo, "lasso di tempo accettabile" non è definito: accettabile per chi e rispetto a quale parametro di riferimento? Il requisito corretto risolve entrambi i problemi specificando le pagine interessate ("pagine di registrazione studenti e iscrizione ai corsi") e fissando un obiettivo misurabile di 5 secondi.
