Requisiti di Sistema: Comprendere e Gestire le Necessità degli Utenti

Analisi Requisiti: Il processo di scoprire, analizzare, documentare e verificare i servizi necessari per un sistema e dei suoi vincoli operativi. Che cosa è un requisito: Si può variare da un alto livello di affermazione astratta di un servizio o un vincolo di sistema per specifiche matematiche funzionali.

Tipi di requisiti:

• Requisiti utente: istruzioni in linguaggio naturale oltre a diagrammi dei servizi e il sistema fornisce i suoi vincoli operativi. Scritto per gli utenti.
• Requisiti di sistema: Un documento strutturato che definisce le descrizioni dettagliate delle funzioni, servizi e vincoli operativi del sistema. Definisce cosa dovrebbe essere attuato, può essere parte di un contratto tra il cliente e lo sviluppatore.

Il sistema LIBSYS: un sistema bibliotecario che fornisce un'unica interfaccia per una serie di voci di database in librerie diverse. Esigenze degli utenti: Client manager, utenti finali, ingegneri di sistema, clienti, fornitori manager, architetti di sistema.

Requisiti di sistema:

Sistema utenti finali, clienti e ingegneri, architetti di sistema, lo sviluppo. Requisiti software funzionali: Descrivere i servizi o le funzionalità di sistema. Dipendono dal tipo di software, utenti previsti e il tipo di sistema in cui viene utilizzato il software. Può essere di alto livello dichiarazioni; i requisiti di sistema funzionale dovrebbero descrivere i servizi di sistema in dettaglio.

Esempio:

L'utente dovrebbe essere in grado di cercare l'intero set iniziale di database o selezionare un sottoinsieme di esso. Il sistema deve fornire agli spettatori appropriati per l'utente di leggere i documenti nel repository dei documenti.

Requisiti non funzionali:

Definiscono le proprietà del sistema e, ad esempio, vincoli di affidabilità, tempi di risposta e le esigenze di storage. Restrizioni alla capacità di dispositivi I/O, le rappresentazioni di sistema, ecc. Possono essere più critici rispetto ai requisiti funzionali.

Esempio:

Requisiti di prodotto, requisiti organizzativi, requisiti esterni.

• Requisiti del prodotto: specificano che il prodotto consegnato deve comportarsi in modo particolare, ad esempio, velocità di esecuzione, affidabilità, ecc.
• Requisiti organizzativi: conseguenza di politiche e procedure dell'organizzazione, ad esempio, standard di processo utilizzato, requisiti di attuazione, ecc.
• Requisiti esterni: fattori esterni al sistema e il suo processo di sviluppo, requisiti di interoperabilità, per esempio, requisiti legislativi, ecc.

Requisiti di dominio:

Derivano dal dominio applicativo e descrivono le caratteristiche del sistema che riflettono il dominio. Possono limitare i requisiti funzionali esistenti o definire calcoli specifici che devono essere eseguiti. Se i requisiti di dominio non sono soddisfatti, il sistema non può funzionare.

Problemi:

• Facilità di comprensione: I requisiti sono espressi nella lingua del dominio applicativo, spesso non compresi dagli ingegneri del software nello sviluppo del sistema.
• Implicita: Gli esperti comprendono il mondo così bene che non pensano di rendere i requisiti di dominio espliciti.

Specifica dei requisiti documento:

Deve essere composto da frasi in linguaggio naturale, seguendo alcune norme:

1. Uso di requisiti obbligatori e "dovrebbe" per esigenze desiderabili. Esempio: "Il sistema dovrebbe" funzionare su PC IBM linea di computer con microprocessore 486 DX o superiore.
2. I requisiti devono essere organizzati logicamente. Il documento di requisiti software dovrebbe essere composto da frasi in linguaggio naturale, seguendo certi schemi.
3. Ogni requisito deve avere un identificatore univoco, per esempio, un identificatore numerico per riferimento futuro.
4. I requisiti software dovrebbero essere divisi in requisiti funzionali e non funzionali.
5. Evita l'uso di gergo informatico.

Format Specification. Requisiti:

IEEE / ANSI 830/1998. (Introduzione >> Panoramica Requisiti specifici > Appendici > Indice)

Problemi con:

• Ambiguità specifiche del linguaggio naturale: I lettori e scrittori del requisito devono interpretare le stesse parole nello stesso modo. Il linguaggio naturale è intrinsecamente ambiguo, dunque, molto difficile.
• Eccessiva flessibilità: La stessa cosa si può dire in diversi modi nella specifica.
• Mancanza di modularizzazione: Le strutture linguistiche sono inadeguate alla struttura dei requisiti di sistema.

Requirements Engineering:

4 fasi: Studio di fattibilità, l'elicitazione dei requisiti e analisi, la validazione dei requisiti, gestione dei requisiti.

Studio di fattibilità:

Decide se sia o meno la pena spendere tempo e fatica con il sistema proposto. Si tratta di un breve studio focalizzato che controlla se il sistema contribuisce agli obiettivi organizzativi; se il sistema può essere implementato utilizzando la tecnologia attuale e nel budget; se il sistema può essere integrato con gli altri.

Elicitazione e analisi dei requisiti:

Raccogliere informazioni sul sistema proposto e la fonte esistenti: documenti, l'organizzazione, le specifiche già esistenti, osservazioni, interviste, ...

Difficoltà gestionali dei requisiti:

I soggetti interessati non sanno quello che vogliono dal sistema e non esprimono ciò che vogliono. Ovviamente, stakeholder esprimono i requisiti con i propri termini; diverse parti interessate hanno esigenze diverse. Fattori politici possono influenzare, in un ambiente dinamico e in continua evoluzione.

Validazione dei requisiti:

È dedicata a dimostrare che i requisiti definiscono il sistema che il cliente vuole in realtà. I costi di errore dei requisiti sono alti e quindi la validazione è molto importante.

• Verifica di validità: Il sistema fornisce le funzioni che meglio supportano le esigenze del cliente?
• Verifica di coerenza: Ci sono dei conflitti nei requisiti?
• Completezza: Tutte le funzioni richieste dal cliente sono incluse?
• Verifica di realismo: I requisiti possono essere implementati con il budget disponibile e la tecnologia?
• Facilità di verifica: I requisiti possono essere controllati?

Requisiti di gestione:

È il processo di gestione delle mutate esigenze durante l'ingegneria dei requisiti e dei sistemi. I requisiti sono inevitabilmente incompleti e incoerenti.

Tracciabilità:

È legata ai rapporti tra i requisiti, le loro fonti e la progettazione del sistema.

• Tracciabilità della fonte: Link dai requisiti agli stakeholder che hanno proposto a questi requisiti.
• Tracciabilità dei requisiti: Collegamenti tra i requisiti di carico.
• Progetto Tracciabilità: Collegamenti dai requisiti ai moduli di progetto.