Analisi dei requisiti software con esempi
charles moore
Ad esempio, nel contesto dell'applicazione bancaria, il requisito funzionale sarà che quando il cliente seleziona "Visualizza saldo", deve essere in grado di guardare il saldo del suo ultimo conto.
Il requisito software può anche essere non funzionale, può essere un requisito prestazionale. Ad esempio, un requisito non funzionale è che ogni pagina del sistema debba essere visibile agli 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 come istruzioni.
Tipi di requisiti
- Requisiti aziendali: Sono requisiti di alto livello che vengono presi dal business case dei progetti. Ad esempio, un sistema di servizi di mobile banking fornisce servizi bancari al Sud-est asiatico. Il requisito aziendale che viene deciso 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 vengono decisi come requisito aziendale
| 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 progettazione: Questi requisiti sono più dettagliati dei requisiti aziendali. Determinano la progettazione complessiva richiesta per implementare i requisiti aziendali. Per la nostra organizzazione educativa, i casi d'uso architettonici e di progettazione sarebbero login, dettagli del corso, ecc. 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 Strumento di pagamento.
Il cliente potrà vedere una dashboard delle fatture in sospeso degli emittenti di fatture registrati. Può aggiungere, modificare ed eliminare un dettaglio dell'emittente della fattura. Il cliente può configurare SMS, avvisi e-mail per diverse azioni di fatturazione. Può vedere la cronologia delle fatture pagate in passato. Gli attori che iniziano questo caso d'uso sono i clienti della banca o il personale di supporto. |
- Requisiti di sistema e integrazione: Al livello più basso, abbiamo requisiti di sistema e di integrazione. È una descrizione dettagliata di ogni singolo requisito. Può essere sotto forma di storie utente che descrivono realmente il linguaggio aziendale quotidiano. I requisiti sono in abbondanti dettagli in modo che gli sviluppatori possano iniziare a codificare. Ecco un esempio di Bill Modulo di pagamento in cui verrà menzionato il requisito per l'aggiunta di un Biller
| Bill Pagamento | Requisiti |
|---|---|
| Aggiungi BillERS |
|
A volte per alcuni progetti potresti non ricevere alcun requisito o documento con cui lavorare. Esistono tuttavia altre fonti di requisiti che è possibile prendere in considerazione per i requisiti o le informazioni, in modo da poter basare la progettazione del software o dei test su tali requisiti. Quindi le altre fonti di requisiti su cui puoi fare affidamento lo sono
Altre fonti di requisiti
- Trasferimento di conoscenze da colleghi o dipendenti che stanno già lavorando a quel progetto
- Parla del progetto con l'analista aziendale, il product manager, il responsabile del progetto e gli sviluppatori
- Analizza la versione precedente del sistema già implementata nel sistema
- Analizzare il vecchio documento dei requisiti del progetto
- Esamina le precedenti segnalazioni di bug: alcune segnalazioni di bug sono state trasformate in richieste di miglioramento che possono essere implementate nella versione corrente
- Guarda nella guida all'installazione se è disponibile per vedere quali sono le installazioni richieste
- Analizza la conoscenza del dominio o del settore che il team sta cercando di implementare
Qualunque sia la fonte del requisito che ottieni, assicurati di documentarli in qualche modo, falli rivedere da altri membri del team esperti e competenti.
Come analizzare i requisiti
Considera l'esempio di un sistema software educativo in cui uno studente può registrarsi a diversi corsi.
Studiamo come analizzare i requisiti. I requisiti devono mantenere una qualità standard dei relativi requisiti, inclusi diversi tipi di qualità dei requisiti
- Atomic
- Identificato in modo univoco
- Completato
- Coerente e inequivocabile
- Tracciabile
- Prioritized
- Testabile
Facciamolo capire con un esempio, ci sono tre colonne nella tabella qui mostrata,
- La prima colonna indica- "qualità del requisito"
- La seconda colonna indica: "cattivo requisito con qualche problema"
- La terza colonna è uguale alla seconda colonna ma - "convertita in un buon requisito".
| Requisiti Qualità | Esempio di cattivo requisito | Esempio di buon requisito |
|---|---|---|
| Atomic |
|
|
| Identificato in modo univoco | 1- Gli studenti potranno iscriversi ai corsi di laurea triennale1- 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 |
| Tracciabile | 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à 1Mantieni informazioni utente-Priorità 1Iscriviti ai corsi-Priorità 1Visualizza pagella-Priorità 1 | Registra studente-Priorità 1Mantieni informazioni utente-Priorità 2Iscrivi corsi-Priorità 1Visualizza 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 |
Ora cerchiamo di capire ciascuno di questi requisiti in dettaglio, iniziando con Atomcircuito integrato.
Atomic
Quindi ogni singolo requisito che hai dovrebbe essere atomico, il che significa che dovrebbe essere a un livello di dettaglio molto basso, non dovrebbe essere possibile separarlo in componenti. Qui vedremo i due esempi per i requisiti, a Atomlivelli di requisiti ic e identificati in modo univoco.
Quindi continuiamo con l'esempio di creazione di un sistema per il dominio dell'istruzione. Qui, il requisito negativo è "Gli studenti potranno iscriversi a corsi di laurea triennale e post-laurea". Questo è un requisito negativo perché non è atomico, perché parla di due entità diverse: corsi di laurea triennale e post-laurea. Quindi ovviamente non è un requisito positivo, ma un requisito negativo, quindi un requisito positivo per la corrispondenza sarebbe quello di separarlo in due requisiti. Quindi uno parla dell'iscrizione a corsi di laurea triennale mentre l'altro parla dell'iscrizione a corsi di laurea triennale.
Identificato in modo univoco
Allo stesso modo, il prossimo requisito di qualità è verificare l'identificazione univoca, qui abbiamo due requisiti separati ma entrambi hanno lo stesso ID n. 1. Quindi, se ci riferiamo al nostro requisito con riferimento all'ID#, ma non è chiaro quale esatto requisito ci riferiamo al documento o ad altra parte del sistema poiché entrambi hanno lo stesso ID#1. Quindi separando con ID univoci, quindi un buon requisito sarà restituito come sezione 1- iscrizioni ai corsi, e ha due requisiti 1.1 id è l'iscrizione ai corsi di laurea mentre 1.2 id è l'iscrizione ai corsi post-laurea.
Completato
Inoltre, ogni singolo requisito dovrebbe essere completo. Ad esempio, qui il cattivo requisito dice che un "utente professore accederà al sistema fornendo il suo nome utente, password e altre informazioni rilevanti". Qui le altre informazioni rilevanti non sono chiare, quindi le altre informazioni rilevanti dovrebbero essere esplicitate in un buon requisito per completare il requisito.
Coerente e inequivocabile
Successivamente ogni singolo requisito dovrebbe essere coerente e non ambiguo, quindi qui ad esempio abbiamo requisiti "Uno studente avrà corsi universitari o corsi post-laurea ma non entrambi" questo è un requisito c'è qualche altro requisito che dice "Alcuni corsi lo faranno essere aperto sia agli studenti universitari che a quelli post-laurea”.
Il problema in questo requisito è che dal primo requisito sembra che i corsi siano divisi in due categorie sotto corsi di laurea e corsi post laurea e lo studente può scegliere uno dei due ma non entrambi. Ma quando leggi altri requisiti, è in conflitto con il primo requisito e dice che alcuni corsi saranno aperti sia a post-laurea che a studenti universitari.
Quindi è ovvio convertire questo cattivo requisito in un buon requisito che è "Uno studente avrà corsi di laurea o corsi post-laurea ma non entrambi". Ciò significa che ogni corso sarà contrassegnato come corso di laurea o corso post-laurea
Tracciabile
Ogni singolo requisito dovrebbe essere tracciabile perché ci sono già diversi livelli di requisito, abbiamo già visto che in cima avevamo requisiti di business, e poi abbiamo requisiti di architettura e design seguiti da requisiti di integrazione del sistema.
Ora, quando convertiamo i requisiti aziendali in requisiti di architettura e progettazione o convertiamo i requisiti di architettura e progettazione in requisiti di integrazione del sistema, deve esserci tracciabilità. Ciò significa che dovremmo essere in grado di prendere ogni singolo requisito aziendale e mapparlo al corrispondente requisito di architettura e progettazione del software. Quindi ecco un esempio di requisito errato che dice "Mantieni le informazioni sullo studente - mappato all'ID richiesta BRD?" l'ID del requisito non è indicato qui.
Quindi, convertendolo in un buon requisito, dice la stessa cosa ma è mappato con l'ID requisito 4.1. Quindi la mappatura dovrebbe essere presente per ogni singolo requisito. Allo stesso modo in cui abbiamo requisiti di mappatura di alto e basso livello, la mappatura è presente anche tra il sistema e il requisito di integrazione al codice che implementa quel requisito e c'è anche una mappatura tra il sistema e il requisito di integrazione al test case che testa quel particolare requisito .
Quindi questa tracciabilità è presente nell'intero progetto
Prioritized
| Prioritized | Studente registrato-Priorità 1 Mantieni informazioni utente-Priorità 1 Iscriversi ai corsi-Priorità 1 Visualizza pagella-Priorità 1 |
Registrati Student-Priorità 1 Mantieni informazioni utente-Priorità 2 Iscriversi ai corsi-Priorità 1 Visualizza pagella-Priorità3 |
Quindi ogni singolo requisito deve avere la priorità, in modo che il team abbia delle linee guida in modo che il requisito possa essere implementato per primo e quale possa essere fatto in seguito. Qui puoi vedere la cattiva priorità ha registrato lo studente, mantiene le informazioni dell'utente e ogni singolo requisito ha dato priorità-1. Tutto non può avere la stessa priorità, quindi è possibile dare la priorità ai requisiti. Quindi l'esempio di un buon requisito qui è che lo studente registrato e l'iscrizione ai corsi hanno la massima priorità 1, mentre il mantenimento delle informazioni dell'utente viene al di sotto con priorità 2 e quindi abbiamo la visualizzazione della pagella con priorità-3
Testabile
| 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 |
Ogni singolo requisito dovrebbe essere verificabile, qui il requisito sbagliato è "ogni pagina del sistema verrà caricata in un intervallo di tempo accettabile". Ora ci sono due problemi con questo requisito: il primo è che ogni pagina significa che possono esserci molte pagine, il che farà saltare gli sforzi di test. L'altro problema è che dice che la pagina verrà caricata in un intervallo di tempo accettabile, ora qual è l'intervallo di tempo accettabile? Accettabile per chi. Dobbiamo quindi convertire l'argomento non testabile in un argomento testabile, che indichi specificamente di quale pagina stiamo parlando “pagine di registrazione degli studenti e di iscrizione ai corsi” e viene anche fornito il periodo di tempo accettabile che è di 5 secondi.
Conclusione
Quindi è così che dobbiamo esaminare ogni singolo requisito al livello appropriato. Ad esempio, se costruiremo un software per quanto riguarda i requisiti di sistema e di integrazione. Dobbiamo esaminare i requisiti di sistema e di integrazione forniti nelle specifiche dei requisiti software o nelle storie degli utenti e applicarli a ogni singolo requisito di qualità. Quindi controlla se ogni singolo requisito è atomico, identificato in modo univoco e completo e così via.