Requisiti software

Metodi per identificare gli usi dei requisiti

Un metodo per identificare gli usi dei requisiti è la dimensione della stabilità. La stabilità può essere espressa in termini di numero di modifiche aspettabili ad ogni requisito basato su esperimenti o conoscenza di eventi certi che incidono sull'organizzazione, sulle funzioni e persone coinvolte nel sistema del software.

Un altro modo di classificare requisiti è distinguere le classi di requisiti in essenziali, condizionali e opzionali.

http://www.quellidiinformatica.org - La community studenti di Ingegneria Informatica di Napoli

Traduzione del documento inglese fornito dalla prof. Fasolino

1. Essenziale. Implica che il software non sarà accettabile a meno che questi requisiti siano previsti e considerati in una maniera convenuta.
2. Condizionale. Implica che questi sono requisiti che migliorerebbero il prodotto software, ma se non sono presenti non lo rendono necessariamente inaccettabile.
3. Opzionale.

Implica una classe di funzioni che possono o non possono essere prese in considerazione. Questo dà allo sviluppatore l'opportunità di proporre qualcosa che amplifichi l'SRS.

4.3.6 Verificabilità

Un SRS è verificabile se, e solamente se, ogni requisito in esso presente è verificabile. Un requisito è verificabile se, e solamente se, esiste un processo finito e reale grazie al quale una persona o macchina possa controllare se il prodotto software soddisfi quel dato requisito. In generale, ogni requisito ambiguo non è verificabile. I requisiti non verificabili includono asserzioni come "buon lavoro", "buona interfaccia utente", "di solito accade". Questi requisiti non possono essere verificabili perché è impossibile definire quantitativamente i termini "buono", "migliore" o "di solito".

L'asserzione che "il programma non entrerà mai"

in un loop infinito" non è verificabile, perché il testing di questa situazione è teoreticamente impossibile.

Un esempio di un'asserzione verificabile è "il risultato del programma sarà disponibile in 20 s di attività x 60% del tempo a disposizione; e sarà prodotto in 30 s di attività x 100% del tempo disponibile. Questa asserzione può essere verificabile perché usa termini concreti e quantità misurabili. Se un metodo non può essere concepito per determinare se il software soddisfa un particolare requisito, allora quel requisito dovrebbe essere rimosso o dovrebbe essere revisionato.

4.3.7 Modificabilità

Un SRS è modificabile se, e solamente se, la sua struttura e il suo stile sono tali che alcune modifiche ai requisiti possono essere fatte facilmente, completamente, e costantemente senza cambiare la struttura e lo stile. La modificabilità, generalmente, richiede che un

SRS:

1. Deve avere una coerenza ed una organizzazione di facile uso con una tabella dei contenuti, un indice, e un glossario di riferimenti esplicito;
2. Non deve essere ridondante (ad esempio, lo stesso requisito non dovrebbe apparire in più punti nell'SRS);
3. Deve esprimere separatamente ogni requisito, piuttosto che mescolarlo con gli altri requisiti.

La ridondanza non è un errore, ma può condurre facilmente ad errori. La ridondanza può aiutare di tanto in tanto a realizzare un SRS più leggibile, ma un problema può sorgere quando il documento ridondante viene aggiornato. Per esempio, un requisito può essere modificato solamente in uno dei punti dove appare. L'SRS diviene a tal punto incoerente.

Ogni qualvolta, la ridondanza è necessaria, l'SRS dovrebbe includere riferimenti incrociati espliciti per favorire la sua modificabilità.

4.3.8 Rintracciabilità

Un SRS è rintracciabile se l'origine di ognuno dei suoi

requisiti è chiara e se facilita la rintracciabilità di ogni requisito in uno sviluppo futuro o prevede una documentazione di arricchimento. I seguenti due tipi di tracciabilità sono particolarmente raccomandati:

La community studenti di Ingegneria Informatica di Napoli

Traduzione del documento inglese fornito dalla prof. Fasolino

a) Tracciabilità all'indietro (ad esempio, a precedenti fasi di sviluppo). Questa implica che ogni requisito citi esplicitamente la sua fonte nei meno recenti documenti.

b) Tracciabilità diretta (ad esempio, a tutti i documenti generati dall'SRS). Questa implica che ogni requisito nell'SRS abbia un nome unico o numero di referenza.

La tracciabilità diretta dell'SRS è particolarmente importante quando il prodotto software entra nella fase di funzionamento e di manutenzione. Quando codici e documenti di progetto vengono modificati, è essenziale

esserecapaci di accertare il set completo di requisiti sul quale si possono ripercuotere queste modifiche.

4.4 Preparazione congiunta dell' SRS

Il processo di sviluppo software dovrebbe cominciare con l'accorso tra cliente e sviluppatore su quello che il software completato dovrà fare. Questo accordo, nella forma di un SRS dovrebbe essere congiuntamente preparato. Questo è importante perché di solito né il cliente né lo sviluppatore riescono a scrivere un buon SRS da soli.

a) Il cliente non capisce di solito abbastanza bene il progetto del software e il processo di sviluppo attraverso un SRS che gli viene fornito.

b) Lo sviluppatore non capisce di solito abbastanza bene il problema del cliente e la quantità di sforzo a specificare requisiti per realizzare un sistema soddisfacente.

Il cliente ed il fornitore dovrebbero collaborare per produrre un completo e ottimo SRS, capito da ambo le parti.

Una situazione particolare si ha quando un sistema

ed il suo software vengono definiti da ambo le parti. Però la funzionalità, l'interfacce, le performance e gli altri attributi e costrizioni del software non sono predefinibili, ma piuttosto sono congiuntamente definite la negoziazione e le modifiche da effettuare. Ciò genera molte più difficoltà, ma non sono meno importanti, per soddisfare le caratteristiche affermate nel 4.3. In particolare, un SRS in cui sia assente la collaborazione tra le diverse parti del sistema è incorretto.

Questa procedura guidata non specifica discussioni su stili, uso della lingua, o tecniche di buona scrittura. Comunque, è piuttosto importante che sia scritto bene un SRS. Libri di scrittura tecnici e generali possono essere usati come guida.

4.5 Evoluzione di SRS

L'SRS può avere bisogno di evolvere qualora lo sviluppo del prodotto software evolve. Può essere impossibile specificare dettagli quando il progetto è iniziato (ad esempio,

Può essere impossibile definire il pannello di visualizzazione per un programma conversazionale durante la fase dei requisiti). Modifiche addizionali possono conseguire a deficienze, mancanze ed imprecisioni che poi vengono scoperti nell' SRS.

Le due considerazioni più rilevanti in questa fase del processo sono le seguenti:

1. i requisiti dovrebbero essere specificati completamente così come sono conosciuti all'istante, anche se revisioni evolutive possono essere previste come inevitabili. Il fatto che essi sono incompleti dovrebbe essere notato.
2. un processo di modifica formale dovrebbe essere iniziato per identificare, controllare, tracciare, e riportare cambiamenti. Modifiche approvate nei requisiti dovrebbero essere incorporate nell' SRS in modo tale che
   1. si abbia una traccia della revisione accurata e completa delle modifiche;
   2. permettere la revisione di porzioni corrette dell'SRS.

www.quellidiinformatica.org - La community

essere usato come mezzo per indurre a suscitare requisiti del software. Caratteristiche come uno schermo o formati di configurazione possono essere estratte direttamente dal prototipo. Gli altri requisiti possono essere inferiti correndo a esperimenti col prototipo.

4.7 Implementazione del progetto nell'SRS

Un requisito specifica una funzione visibile all'esterno o un attributo di un sistema. Un design descrive un particolare sottocomponente di un sistema e/o le sue interfacce con altri sottocomponenti. Il relatore di un SRS deve chiaramente distinguere tra l'identificazione di vincoli di design richiesti e la proiezione di uno specifico design. Notare che ogni requisito nell'SRS limita le alternative nella fase di design. Questo non vuole dire, tuttavia, che ogni requisito è un progetto (design).

L'SRS dovrebbe specificare quali funzionalità saranno compiute su quali dati di input, per produrre quali risultati, in quale contesto e a chi. L'SRS

Il tuo compito è formattare il testo fornito utilizzando tag html.

ATTENZIONE: non modificare il testo in altro modo, NON aggiungere commenti, NON utilizzare tag h1;

dovrebbe concentrarsi sui servizi che devono essere realizzati. L’SRS non deve normalmente specificare argomenti di design come i seguenti:

1. suddivisione del software in moduli;
2. istanziazione di funzionalità in moduli;
3. descrizione del flusso di informazioni o controllo tra moduli;
4. scelta di struttura dei dati.

4.7. 1 requisiti di design necessari

In casi speciali, alcuni requisiti possono restringere severamente la fase di progetto. Per esempio, la sicurezza o requisiti di sicurezza possono influenzare direttamente un progetto quando:

1. si deve tenere alcune funzioni in moduli separati;
2. si deve permettere una comunicazione limitata tra alcune aree del programma;
3. si deve controllare l'integrità dei dati per variabili critiche.

Esempi di vincoli di design valide sono requisiti fisici, requisiti di performance, sviluppo del software standard e standard per assicurare la qualità del software.

Perciò, i requisiti dovrebbero essere rappresentati da

un punto di vista puramente esterno. Quando si usano modelli per rappresentare i requisiti, si ricorda che il modello indica solamente il comportamento esterno, e non specifica un