features functional requirements
Questo tutorial spiega i tipi, le caratteristiche, il confronto tra requisiti funzionali e non funzionali e requisiti aziendali e funzionali con esempi:
I requisiti funzionali definiscono cosa dovrebbe fare un sistema software. Definisce una funzione di un sistema software o del suo modulo. La funzionalità è misurata come un insieme di input al sistema in prova all'output dal sistema.
L'implementazione dei requisiti funzionali in un sistema è pianificata nella fase di progettazione del sistema mentre, in caso di requisiti non funzionali, è prevista nel documento Architettura del sistema. Il requisito funzionale supporta la generazione dei requisiti non funzionali.
Cosa imparerai:
Requisiti funzionali e requisiti non funzionali
Richieste funzionali
Cerchiamo di capire quali sono i requisiti funzionali con l'aiuto di esempi-
Esempio: In un progetto ADAS automobilistico, un requisito funzionale del sistema di visione surround potrebbe essere 'La telecamera posteriore dovrebbe rilevare una minaccia o un oggetto'. I requisiti non funzionali qui potrebbero essere 'la velocità con cui deve essere visualizzato l'avviso a un utente quando una minaccia viene rilevata dai sensori della telecamera'.
Prendine un altro esempio del progetto Sistemi di infotainment. L'utente abilita il Bluetooth qui dall'HMI e controlla se il Bluetooth è abilitato o meno. Nota , altri servizi Bluetooth vengono abilitati (dal grigio al grassetto) quando l'utente abilita il Bluetooth.
cos'è la gestione dei dati di test nel test del software
Quindi, i requisiti funzionali parlano di un particolare risultato del sistema quando un'attività viene eseguita su di essi dall'utente. D'altra parte, il requisito non funzionale fornisce il comportamento complessivo del sistema o dei suoi componenti e non sulla funzione.
Tipi di requisiti funzionali
I requisiti funzionali potrebbero includere i seguenti componenti che possono essere misurati come parte del test funzionale:
# 1) Interoperabilità: Il requisito descrive se un sistema software è interoperabile tra sistemi diversi.
Esempio: Per i requisiti funzionali Bluetooth nel sistema di infotainment dell'auto, quando l'utente abbina uno smartphone Android abilitato Bluetooth a un sistema di infotainment basato su QNX, dovremmo essere in grado di trasferire la rubrica al sistema di infotainment o riprodurre musica in streaming dal nostro dispositivo telefonico al sistema di infotainment.
Quindi l'interoperabilità controlla se la comunicazione tra i due diversi dispositivi è possibile o meno.
Un altro esempio proviene dai sistemi di servizi di posta elettronica come Gmail. Gmail consente l'importazione di e-mail da un altro server di scambio di posta come Yahoo.com o Rediffmail.com. Ciò è possibile grazie all'interoperabilità tra i server di posta elettronica.
# 2) Sicurezza: Il funzionale requisito descrive l'aspetto della sicurezza dei requisiti software.
Esempio: Servizi basati su Cyber Security nel sistema basato su telecamera surround ADAS che utilizza Controller Area Network (CAN) che protegge il sistema dalle minacce alla sicurezza.
Un altro esempio proviene dal sito di social networking Facebook . I dati di un utente devono essere protetti e non devono essere divulgati a terzi. Ci auguriamo che questo esempio di Facebook offra ai lettori una visione più ampia della sicurezza a causa della recente incidenza della violazione dei dati su Facebook e delle conseguenze affrontate da Facebook.
# 3) Precisione: La precisione definisce che i dati inseriti nel sistema vengono calcolati correttamente e utilizzati dal sistema e che l'output è corretto.
Esempio: Nella Controller Area Network, quando un valore di segnale CAN viene trasmesso su CAN bus da una ECU (vale a dire unità ABS, unità HVAC, unità quadro strumenti, ecc.), Un'altra ECU sarà in grado di identificare se i dati inviati sono corretti o meno tramite controllo CRC.
Un altro esempio può provenire da una soluzione di banking online. Quando l'utente riceve un fondo, l'importo ricevuto deve essere esattamente accreditato sul conto e non viene accettata alcuna variazione dell'accuratezza.
# 4) Conformità: I requisiti funzionali di conformità convalidano che il sistema sviluppato è conforme agli standard industriali.
Esempio: Se le funzionalità dei profili Bluetooth (vale a dire streaming audio tramite A2DP, telefonata tramite HFP) sono compatibili con le versioni del profilo di rilascio Bluetooth SIG.
Un altro esempio può essere quello del gioco Apple Car nel sistema di infotainment per auto. L'App nell'infotainment ottiene un certificato da Mela se tutte le condizioni preliminari menzionate nel sito web di Apple sono soddisfatte da dispositivi Car Play di terze parti (infotainment in questo caso).
Un altro esempio può provenire da un'applicazione basata sul Web per il sistema di biglietteria ferroviaria. Il sito web dovrebbe seguire le linee guida sulla sicurezza informatica e rispettare il World Wide Web in termini di accessibilità.
Esempio di modulo dei requisiti:
Abbiamo già visto quale sia il requisito funzionale con alcuni esempi. Vediamo ora come apparirebbe un requisito funzionale quando integrato in strumenti di gestione dei requisiti come IBM DOORS. Ci sono più attributi da prendere in considerazione durante la documentazione di un requisito funzionale nello strumento di gestione dei requisiti.
Di seguito sono riportati alcuni attributi da prendere in considerazione:
- Tipo di oggetto: Questo attributo spiega quale sezione del documento dei requisiti fa parte di questo attributo. Potrebbero essere Intestazione, Spiegazione, Requisito, ecc. Per lo più la sezione 'Requisito' è considerata per l'implementazione e il test, mentre le sezioni di intestazione e spiegazione sono utilizzate come descrizioni di supporto per i requisiti per una migliore comprensione.
- Persona responsabile: Un autore che ha documentato il requisito nello strumento di gestione dei requisiti.
- Nome progetto / sistema: Il progetto per il quale è applicabile il requisito, per esempio, 'Sistemi di infotainment per XYZ OEM (Original Equipment Manufacturer) una società automobilistica o applicazione Web per la società per azioni ABC banking'.
- Numero di versione del requisito: Questo campo / attributo notifica il numero di versione del requisito se il requisito ha subito più modifiche a causa di aggiornamenti del cliente o modifiche nella progettazione del sistema.
- ID requisito: Questo attributo menziona l'ID requisito univoco. L'ID requisito viene utilizzato per monitorare facilmente i requisiti nel database e anche per mappare i requisiti nel codice in modo efficiente. Può anche essere utilizzato per fornire un riferimento ai requisiti durante la registrazione dei difetti negli strumenti di tracciamento dei bug.
- Descrizione del requisito: Questo attributo è uno degli attributi più importanti che spiegano il requisito. Leggendo questo attributo, un ingegnere sarebbe in grado di comprendere il requisito.
- Stato requisito: L'attributo dello stato del requisito indica lo stato di un requisito nello strumento di gestione dei requisiti, ovvero se è stato accettato, sospeso, rifiutato o eliminato il progetto.
- Commenti: Questo attributo fornisce alla persona responsabile o al manager del requisito un'opzione per documentare qualsiasi commento sul requisito. Esempio: un possibile commento per un requisito funzionale potrebbe essere 'dipendenza da un pacchetto software di terze parti per implementare il requisito'.
Un'istantanea da DOORS
Derivazione dei requisiti funzionali dai requisiti aziendali
Questo è già trattato come parte della sezione ' Derivazione dei requisiti funzionali dai requisiti aziendali ' sotto il Analisi dei requisiti articolo.
Requisiti aziendali vs requisiti funzionali
Questa differenza è vagamente trattata in Analisi dei requisiti articolo. Tuttavia, proveremo a farlo evidenzia alcuni punti in più qui nella tabella sottostante:
| Sl. No. | Requisiti aziendali | Richieste funzionali |
|---|---|---|
| 7 | Per esempio, nel sistema bancario online un requisito aziendale potrebbe essere 'Come utente, dovrei essere in grado di ottenere un estratto conto delle transazioni in contanti'. | Il requisito funzionale in questo sistema di banking online potrebbe essere: 'Quando l'utente fornisce l'intervallo di date nella query di transazione, questo input viene utilizzato dal server e la pagina web viene fornita con i dati di transazione in contanti necessari'. |
| 1 | I requisiti aziendali dicono 'cosa' aspetto dei requisiti del cliente. Esempio, Cosa dovrebbe essere visibile all'utente dopo che l'utente ha effettuato l'accesso. | I requisiti funzionali indicano l'aspetto 'come' dei requisiti aziendali. Esempio, Come la pagina web dovrebbe visualizzare la pagina di accesso dell'utente quando l'utente si autentica. |
| Due | I requisiti aziendali vengono identificati dagli analisti aziendali. | I requisiti funzionali sono creati / derivati da sviluppatori / architetto software |
| 3 | Sottolineano il vantaggio per l'organizzazione e sono correlati agli obiettivi aziendali. | Il loro obiettivo è l'adempimento dei requisiti del cliente. |
| 4 | I requisiti aziendali provengono dal cliente. | I requisiti funzionali derivano dai requisiti software, che a loro volta derivano dai requisiti aziendali. |
| 5 | I requisiti aziendali non vengono testati direttamente dagli ingegneri di test del software. Sono principalmente testati dal cliente. | I requisiti funzionali sono testati dagli ingegneri di Software Test e generalmente non testati dai clienti. |
| 6 | Il requisito aziendale è un documento con requisiti di alto livello. | Un requisito funzionale è un documento dettagliato dei requisiti tecnici. |
Requisito non funzionale
Il requisito non funzionale dice di 'cosa dovrebbe essere un sistema' piuttosto che 'cosa dovrebbe fare un sistema' (requisito funzionale). Sono per lo più derivati da requisiti funzionali basati sull'input del cliente e di altri stakeholder. I dettagli sull'implementazione dei requisiti non funzionali sono documentati nel documento Architettura di sistema.
I requisiti non funzionali spiegano gli aspetti di qualità del sistema da costruire, vale a dire. prestazioni, portabilità, usabilità, ecc. I requisiti non funzionali, a differenza dei requisiti funzionali, vengono implementati in modo incrementale in qualsiasi sistema.
URPS (Usabilità, affidabilità, prestazioni e supporto) da FURPS (Funzionalità, Usabilità, Affidabilità, Prestazioni e Supportabilità) attributi di qualità ampiamente utilizzati nel settore IT per misurare la qualità di uno sviluppatore di software, sono tutti coperti da requisiti non funzionali. Inoltre, ci sono anche altri attributi di qualità (dettagli nella prossima sezione).
Wikipedia chiama il requisito non funzionale a volte come 'ilities', a causa della presenza di vari attributi di qualità come la portabilità e la stabilità.
Tipi di requisiti non funzionali
I requisiti non funzionali sono i seguenti sottotipi (non esaustivi):
# 1) Prestazioni:
Un tipo di attributo di prestazione di requisito non funzionale misura le prestazioni del sistema. Esempio: Nel sistema di visualizzazione surround ADAS, 'la vista della telecamera posteriore deve essere visualizzata entro 2 secondi dall'avvio dell'accensione dell'auto'.
Un altro esempio delle prestazioni potrebbe provenire da un sistema di navigazione di sistemi di infotainment. 'Quando un utente va alla schermata di navigazione e inserisce la destinazione, il percorso deve essere calcolato entro' X 'secondi'. Ancora uno esempio dalla pagina di accesso dell'applicazione web. 'Tempo necessario per il caricamento della pagina del profilo utente dopo l'accesso.'
Ricorda che la misurazione delle prestazioni del sistema è diversa dalla misurazione del carico. Durante il test di carico, carichiamo la CPU e la RAM del sistema e controlliamo il throughput del sistema. Nel caso delle prestazioni, testiamo il rendimento del sistema in condizioni di carico / stress normali.
# 2) Usabilità :
L'usabilità misura l'usabilità del sistema software in fase di sviluppo.
Per esempio , viene sviluppata un'applicazione web per dispositivi mobili che fornisce informazioni sulla disponibilità di idraulici ed elettricisti nella tua zona.
L'input per questa app è il codice postale e il raggio (in chilometri) dalla posizione corrente. Ma per inserire questi dati, se l'utente deve navigare attraverso più schermate e l'opzione di immissione dei dati viene visualizzata in piccole caselle di testo che non sono prontamente visibili a un utente, allora questa app non è user-friendly e quindi l'usabilità dell'app sarà molto basso.
# 3) Manutenibilità :
La manutenibilità di un sistema software è la facilità con cui il sistema può essere mantenuto. Se il tempo medio tra i guasti (MTBF) è basso o il tempo medio per la riparazione (MTTR) è alto per il sistema in fase di sviluppo, la manutenibilità del sistema è considerata bassa.
La manutenibilità viene spesso misurata a livello di codice utilizzando la complessità ciclomatica. La complessità ciclomatica dice che meno complesso è il codice, più facile è mantenere il software.
Esempio: Viene sviluppato un sistema software che ha un numero elevato di codici morti (codici non utilizzati da altre funzioni o moduli), altamente complesso a causa dell'uso eccessivo di condizioni if / else, loop annidati, ecc. O se il sistema è enorme con codici in esecuzione in molti milioni di righe di codice e nessun commento appropriato. Un tale sistema è a bassa manutenibilità.
Un altro esempio potrebbe essere di una pagina web per lo shopping online. Se sul sito Web sono presenti molti collegamenti esterni in modo che l'utente possa avere una panoramica del prodotto (questo per risparmiare sulla memoria), la manutenibilità di questo sito Web è bassa. Questo perché, se il collegamento a una pagina Web esterna cambia, deve essere aggiornato anche sul sito Web per lo shopping online e troppo frequentemente.
# 4) Affidabilità :
L'affidabilità è un altro aspetto della disponibilità. Questo attributo di qualità sottolinea la disponibilità di un sistema in determinate condizioni. Viene misurato come MTBF proprio come la manutenibilità.
Esempio: Funzionalità che si escludono a vicenda come telecamera per la retromarcia e Trailer nel sistema di telecamere surround ADAS dovrebbero funzionare in modo affidabile nel sistema senza alcuna interferenza tra loro. Quando un utente richiama la funzione Trailer, lo specchietto retrovisore non dovrebbe interferire e viceversa poiché entrambe le funzioni accedono alla telecamera posteriore dell'auto.
Un altro esempio dal sistema di richiesta di risarcimento in linea. Quando un utente avvia la segnalazione dei reclami e quindi carica le note spese pertinenti, il sistema dovrebbe concedere tempo sufficiente per il completamento del caricamento e non annullare rapidamente il processo di caricamento.
# 5) Portabilità:
Portabilità significa la capacità di un sistema software di funzionare in un ambiente diverso se il framework dipendente sottostante rimane lo stesso.
Esempio: Il sistema / componente software in un sistema di infotainment sviluppato (vale a dire servizio Bluetooth o servizio multimediale) per un produttore di autoveicoli dovrebbe consentire di essere utilizzato in un altro sistema di infotainment con poche o nessuna modifica nel codice, sebbene i due sistemi di infotainment siano completamente diversi .
Prendiamone un altro esempio da WhatsApp. È possibile installare e utilizzare il servizio di messaggistica su IOS, Android, Windows, tablet, laptop e telefono.
# 6) Supportabilità:
La funzionalità di un sistema software è la capacità di un esperto tecnico / dell'assistenza di installare il sistema software in un ambiente in tempo reale, monitorare il sistema mentre è in esecuzione, identificare eventuali problemi tecnici nel sistema e fornire una soluzione per risolvere il problema.
La manutenzione è possibile se il sistema è sviluppato per facilitare la manutenzione.
Esempio: Fornire un popup di promemoria periodico all'utente per un aggiornamento software, fornire un meccanismo di registrazione / traccia per eseguire il debug dei problemi, ripristino automatico in caso di errore tramite meccanismo di rollback (ripristinare il sistema software allo stato precedente della condizione di lavoro)
Un altro esempio a partire dal Rediffmail. Quando c'era un aggiornamento nella versione del servizio di posta basato sul web, il sistema consentiva all'utente di passare a una versione più recente del sistema di posta mantenendo intatta quella precedente per alcuni mesi. Ciò migliora anche l'esperienza dell'utente.
# 7) Adattabilità:
L'adattabilità di un sistema è definita come la capacità di un sistema software di adattarsi al cambiamento in un ambiente senza alcun cambiamento nel suo comportamento.
Esempio: Il sistema antibloccaggio in auto dovrebbe funzionare di serie in tutte le condizioni atmosferiche (caldo o freddo). Un altro esempio potrebbe essere quello di un sistema operativo Android. È utilizzato in diversi tipi di dispositivi, vale a dire. Smartphone, tablet e sistemi di infotainment e sono altamente adattabili.
Oltre ai 7 requisiti non funzionali sopra elencati, ne abbiamo molti altri come:
Accessibilità, backup, capacità, conformità, integrità dei dati, conservazione dei dati, dipendenza, distribuzione, documentazione, durabilità, efficienza, sfruttamento, estensibilità, gestione dei guasti, tolleranza agli errori, interoperabilità, modificabilità, operabilità, privacy, leggibilità, reporting, resilienza, riusabilità, Robustezza, scalabilità, stabilità, testabilità, produttività, trasparenza, integrabilità.
La copertura di tutti questi requisiti non funzionali è al di fuori dello scopo di questo articolo. Tuttavia, puoi leggere ulteriori informazioni su questi tipi di requisiti non funzionali in Wikipedia.
Derivazione di requisiti non funzionali da requisiti funzionali
I requisiti non funzionali possono essere derivati in molti modi, ma il modo migliore e più provato e testato dalle industrie è dai requisiti funzionali.
Prendiamo l'esempio dai nostri sistemi di infotainment che abbiamo già preso in alcuni punti in questo articolo. L'utente può eseguire molte azioni sul sistema Infotainment, vale a dire. cambiare il brano, cambiare la sorgente del brano da USB a FM o audio Bluetooth, impostare la destinazione di navigazione, aggiornare il software di infotainment tramite un aggiornamento software, ecc.
# 1) Raccolta dei requisiti non funzionali:
Elencheremo le attività eseguite da un utente, che fa parte dei requisiti funzionali. Una volta che le azioni dell'utente sono state annotate nel diagramma del caso d'uso UML (ogni ovale), avvieremo domande pertinenti (ogni rettangolo) sulle azioni di ogni utente. Le risposte a queste domande forniranno i nostri requisiti non funzionali.
# 2) Classificazione dei requisiti non funzionali:
Il passaggio successivo è la categorizzazione dei requisiti non funzionali che abbiamo identificato tramite domande. In questa fase, possiamo verificare la possibile risposta e classificare le risposte a possibili categorie non funzionali o qualità diverse.
supporta le domande e le risposte dell'intervista ai tecnici
Nell'immagine sottostante puoi vedere i possibili attributi di qualità identificati dalle risposte.
Requisiti funzionali e non funzionali
Abbiamo già visto cosa sono i requisiti funzionali e non funzionali e come vengono derivati. Diamo uno sguardo alle principali differenze tra requisiti funzionali e non funzionali.
| Sl. no | Requisiti funzionali (FR) | Requisiti non funzionali (NFR) |
|---|---|---|
| 7 | I requisiti funzionali costituiscono lo scheletro dell'implementazione del sistema software | I requisiti non funzionali completano il sistema SW aiutando i requisiti funzionali a restare uniti, come un muscolo. |
| 1 | Dicono, cosa dovrebbe fare un sistema. | Dicono, come dovrebbe essere un sistema. |
| Due | Sono descritti in dettaglio nel documento System Design. | Sono descritti in dettaglio nel documento sull'architettura del sistema. |
| 3 | Parlano del comportamento di una funzione o di una caratteristica. | Parlano del comportamento lavorativo di un intero sistema o di un componente del sistema e non di una particolare funzione. |
| 4 | L'utente passerà l'input e verificherà se l'output è visualizzato correttamente. | Quando l'utente passa un input, gli NFR possono rispondere alle seguenti domande: i) Quanto tempo ci vuole per visualizzare l'output? ii) L'output è coerente con il tempo? iii) Esistono altri modi per passare il parametro di input? iv) Quanto è facile passare il parametro di input? |
| 5 | In un'applicazione web, l'utente dovrebbe essere in grado di accedere tramite autenticazione FR | In un'applicazione web, quanto tempo ci vuole per accedere al sito web, aspetto grafico della pagina di accesso, facilità d'uso di una pagina web, ecc. Fanno parte di NFR |
| 6 | I requisiti funzionali derivano innanzitutto dai requisiti software. | I requisiti non funzionali derivano dai requisiti funzionali. |
| 8 | I requisiti funzionali possono esistere senza un requisito non funzionale. | I requisiti non funzionali non possono esistere senza requisiti funzionali. |
| 9 | Un requisito funzionale fornisce informazioni concrete su una caratteristica, Esempio , La foto del profilo su Facebook dovrebbe essere visibile al login. | Un requisito funzionale può avere molti attributi di requisiti non funzionali. Esempio, tempo di accesso (prestazioni), aspetto della pagina del profilo (usabilità), numero di utenti che possono accedere contemporaneamente (capacità, prestazioni) |
| 10 | È possibile derivare requisiti funzionali da requisiti SW per quasi tutti i requisiti aziendali | Spesso non si riesce a documentare gli NFR, poiché non vengono poste domande rilevanti sugli FR. |
| undici | L'implementazione di un requisito funzionale viene normalmente eseguita in una build software. | Gli NFR vengono implementati durante tutto il ciclo di vita del progetto fino a quando non si ottiene il comportamento desiderato. |
| 12 | Questi sono per lo più visibili al cliente. | Questi non sono per lo più visibili al cliente, ma potrebbero essere sperimentati a lungo termine. Esempio, L'usabilità, le prestazioni, ecc. Possono essere sperimentate solo a lungo termine ma non possono essere affatto visibili. |
Conclusione
I requisiti costituiscono l'elemento costitutivo di base per sviluppare qualsiasi sistema software. È possibile costruire un sistema con requisiti funzionali ma le sue capacità non possono essere determinate né misurate. Detto questo, è molto importante avere requisiti funzionali di buona qualità derivati da un requisito aziendale di avere un sistema software funzionante di alta qualità.
Quindi, i requisiti funzionali danno la direzione dell'implementazione di un sistema software, ma i requisiti non funzionali determinano la qualità dell'implementazione che gli utenti finali sperimenteranno.
Lettura consigliata
- Come testare la specifica dei requisiti software (SRS)?
- Test funzionale vs test non funzionale
- Come testare un'applicazione senza requisiti?
- Che cos'è l'analisi e la raccolta dei requisiti in SDLC?
- 5 errori mortali nella gestione dei requisiti e come superarli
- Caratteristiche dei requisiti funzionali e dei requisiti non funzionali
- Come creare la matrice di tracciabilità dei requisiti (RTM): esempio e modello di esempio
- I 20 migliori strumenti per la gestione dei requisiti (l'elenco completo)