Che materia stai cercando?

Requisiti software Appunti scolastici Premium

Appunti della professoressa Fasolino di ingegneria del software. Il file contiene una trattazione sulla procedura raccomandata per le specifiche dei requisiti software. Il file contiene inoltre: i documenti ISEE standard, sviluppo e preparazione dell'SRS.

Esame di Fondamenti di informatica docente Prof. R. Fassolino

Anteprima

ESTRATTO DOCUMENTO

Traduzione del documento inglese fornito dalla prof. Fasolino

requisiti del ciclo di vita del software ed è usato nel disegno, nell'esecuzione, nel controllo del progetto, nella verifica e

convalida e nel funzionamento come descritto in IEEE lo Std 1074-1997. Lo SRS dovrebbe essere inequivocabile sia a

coloro che lo scrivono che a coloro che lo usano. Tuttavia, questi gruppi non hanno spesso lo stesso punto di vista e

quindi non tendono a descrivere i requisiti del software nel loro senso. Le rappresentazioni che migliorano la specifica

dei requisiti per lo sviluppatore possono essere controproducenti in quanto diminuiscono la possibilità di far capire

all'utente e viceversa. Le preposizioni subordinate da 4.3.2.1 a 4.3.2.3 suggeriscono come evitare l'ambiguità.

4.3.2.1 Trabocchetti del linguaggio naturale

I requisiti sono scritti spesso in linguaggio naturale (per esempio, inglese). Il linguaggio naturale è inerentemente

ambiguo. Un linguaggio naturale SRS dovrebbe essere rivisto da una figura indipendente per identificare l'uso ambiguo

della lingua in modo da poterlo correggere.

4.3.2.2 Linguaggi di specifica dei requisiti

Un modo per evitare l'ambiguità inerente il linguaggio naturale è quello di scrivere l’SRS in una lingua particolare di

specifica di requisiti. Questo linguaggio rileva automaticamente molti errori del lessico, sintattici e semantici. Uno

svantaggio nell'uso di tali lingue è la durata richiesta a impararle. Inoltre, questi linguaggi tendono ad essere migliori

nll'esprimere determinati tipi di requisiti ed a richiamare determinati tipi di sistemi. Quindi, possono influenzare i

requisiti in modo sottile.

4.3.2.3 Strumenti di rappresentazione

In generale, metodi di requisiti e linguaggi e gli attrezzi che sono presi come supporto cadono nelle seguenti categorie

generali –oggetto, processo, comportamento. I metodi orientati agli oggetti organizzano i requisiti in termini di oggetti

nell'ambiente, loro attributi e servizi prestati da quegli oggetti. I metodi basati su processi organizzano i requisiti nelle

gerarchie delle funzioni che comunicano mediante i flussi di dati. I metodi di comportamento descrivono il

comportamento esterno del sistema in termini astratti (quale il calcolo di attributo), funzioni matematiche, o stato delle

macchine. Il grado a cui tali attrezzi e metodi possono essere utili nella preparazione dello SRS dipende dal formato

e dalla complessità del programma. Nessun tentativo è fatto qui per descrivere o citare tutto l'attrezzo particolare.

Quando viene usato uno tra questi metodi è meglio mantenere le descrizioni in linguaggio naturale. In modo che clienti

non pratici con le notazioni possano capire l’ SRS.

4.3.3 Completo

Un SRS è completo se e soltanto se, include i seguenti elementi: a) tutti i requisiti significativi, anche per quanto

riguarda funzionalità, le prestazioni, i vincoli di design, gli attributi, o le interfacce esterne. In particolare tutti i requisiti

esterni imposti da una specifica di sistemadovrebbero essere riconosciuti e trattati.

b) Definizione delle risposte del software a tutte le classi realizzabili dei dati di input. Si noti che è importante

specificare le risposte sia ai valori validi che non validi dell'input.

c) Etichette e riferimenti completi a tutte le figure, tabelle e schemi nell’SRS e nelle definizioni di tutti i termini e nelle

unità della misura.

4.3.3.1 L'uso di TBDs

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

Traduzione del documento inglese fornito dalla prof. Fasolino

Un SRS che usa la frase “deve essere determinato” (TBD) non è un SRS completo. Il TBD è necessario, tuttavia,

occasionalmente e dovrebbe essere accompagnato dalla descrizione di a) circostanze che causano il TBD (per esempio,

perchè una risposta non è conosciuta) così che la situazione possa essere risolta; b) Una descrizione di che cosa deve

essere fatto per eliminare il TBD, chi è responsabile della relativa eliminazione e quando deve essere eliminata.

4.3.4 LA CONSISTENZA

Consistenza si riferisce alla consistenza interna. Se un SRS non prosegue con un certo documento di più alto

livello, come una specifica di requisiti del sistema, esso non è corretto (veda 4.3.1).

4.3.4.1 Consistenza Interna

Uno SRS è internamente consistente se e soltanto se, nessun sottoinsiemedi diversi requisiti descritti in esso è in

conflitto. I tre tipi di conflitto probabili in uno SRS sono: a) le caratteristiche specificate degli oggetti nell'ambiente

possono essere in conflitto. Per esempio, 1) la disposizione di un rapporto di uscita può essere descritta in un requisito

tabulare ma in un altro come testuale. 2) un requisito può dichiarare che tutte le luci saranno verdi mentre un altro può

dichiarare che tutte le luci saranno blu. b) Ci può essere conflitto logico o temporale fra due azioni specificate. Per

esempio, 1) un requisito può specificare che il programma aggiungerà due input ed un altro può specificare che il

programma li moltiplicherà. 2) un requisito può dichiarare che A segue sempre B mentre un altro dice che avvengono

simultaneamente. c) Due o più requisiti possono descrivere lo stesso oggetto nell'ambiente ma usare i termini differenti

per quell'oggetto. Per esempio, la richiesta di un programma per un input dell 'utente può essere denominata prompt in

un requisito e cue in un altro. L'uso di terminologia e di definizioni standard promuove la consistenza.

4.3.5 Allineamento per importanza e/o stabilità

Un SRS è classificato per la stabilità e/o l'importanza se ogni suo requisito ha un identificatore per indicare sia

l'importanza che la stabilità di quel particolare requisito. Tipicamente, tutti i requisiti che si riferiscono ad un prodotto

del software non sono ugualmente importanti. Alcuni requisiti possono essere essenziali, specialmente per applicazioni

vitali e critiche, mentre altri possono essere solo desiderabili.

Ogni requisito nell’ SRS dovrebbe essere identificato per rendere queste differenze chiare ed esplicite. Identificando i

requisiti nella maniera seguente aiutano:

un) ad avere clienti che prestino più considerazione ad ogni requisito, avendo chiara qualsiasi assunzioni ignota che loro

possono avere.

b) ad obbligare gli sviluppatore a prendere decisioni sulla progettazione corrette e dirette a livelli adatti di sforzo alle

diverse parti del prodotto del software.

4.3.5.1 Grado di stabilità

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.

4.3.5.2 Grado della necessità

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

a) Essenziale. Implica che il software non sarà accettabile a meno che questi requisiti siano previsti e considerati in una

maniera convenuta.

b) Condizionale. Implica che questi sono requisiti che migliorerebbero il prodotto software, ma se non sono presenti

non lo rendono necessariamente inaccettabile.

c) Opzionale. Implica una classe di funzioni che possono o non possono essere presi in considerazione. Questo dà allo

sviluppatore l'opportunità di proporre qualche cosa 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 nonverificabili

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:

a) abbia una coerenza ed una organizzazione di facile uso con una tabella dei contenuti, un indice, e un glossario di

riferimenti esplicito;

b) non sia ridondante (ad esempio, lo stesso requisito non dovrebbe apparire in più punti nell’SRS);

c) esprima 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 in 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 arrichhimento. I seguenti due tipi di tracciabilità sono

particolarmente raccomandati:

http://www.quellidiinformatica.org – 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 essere

capaci 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 specifichi

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:

a) 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.

b) 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.

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

Traduzione del documento inglese fornito dalla prof. Fasolino

4.6 Prototipizzazione

La prototipizzazione è usata durante la varie fasi di preparazione dei requisiti di un progetto in modo molto frequente.

Esistono molti metodi per realizzare un prototipo, esibendo delle caratteristiche di un sistema, creandolo molto

rapidamente e facilmente. Vedere anche ASTM E1340-96.

I prototipi sono utili per le seguenti ragioni:

a) può essere molto probabile che il cliente preferisca il prototipo e interagire con esso, invece di leggere l’SRS e

interagire con esso. Infatti, il prototipo è di più rapida reazione.

b) il prototipo espone aspetti inaspettati del comportamento dei sistemi. Non solo produce risposte ma anche domande

nuove. Questo aiuta la finalizzazione di un ricco SRS.

c) un SRS basato su un prototipo tende a subire meno modifiche durante lo sviluppo, accorciando così tempo nello

sviluppo.

Un prototipo dovrebbe 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 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 dovrebbe concentrarsi sui servizi che devono essere realizzati. L’SRS non deve

normalmente specificare argomenti di design come i seguenti:

a) suddivisione del software in moduli;

b) istanziazione di funzionalità in moduli;

c) descrizione del flusso di informazioni o controllo tra moduli;

d) 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

a) si deve tenere alcune funzioni in moduli separati;

b) si deve permettere una comunicazione limitata tra alcune aree del programma;

c) 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

progetto.

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

Traduzione del documento inglese fornito dalla prof. Fasolino

4.8 Implementazione dei requisiti di progetto nell’SRS

L’ SRS dovrebbe riferirsi al prodotto software, non al processo di produzione del prodotto software.

I requisiti di progetto rappresentano la comprensione tra cliente ed sviluppatore su questioni contrattuali che concernono

la produzione di software e perciò non dovrebbero essere inclusi nell’SRS. Questi normalmente prevedono punti come

a) costo;

b) tempi di consegna;

c) Report di procedure;

d) metodi di sviluppo di software;

e) assicurazioni di qualità;

f) criterio di verifica e convalida;

g) procedure di accettazione.

I requisiti di progetto sono specificati in altri documenti, tipicamente in un piano di sviluppo di software, in un piano di

assicurazione di qualità del software, o un contratto di lavoro.

5. Le parti di un SRS

Questa clausola discute ognuna delle parti essenziali dell’SRS. Queste parti sono sistemate in Figura 1 in un riquadro

che può servire per esempio per scrivere un SRS.

Un buon SRS dovrebbe includere tutte le informazioni discusse qui.

5.1 introduzione (Sezione 1 del SRS)

L'introduzione dell’ SRS dovrebbe realizzare una visione d'insieme dell’SRS intero. Dovrebbe contenere le seguenti

sottosezioni:

a) Propositi;

b) Obiettivo;

c) Definizioni, acronimi, e le abbreviazioni;

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

Traduzione del documento inglese fornito dalla prof. Fasolino

d) le Referenze;

e) la Veduta d'insieme.

5.1.1 Propositi (1.1 del SRS)

Questa sottosezione deve

a) delineare lo scopo del l’SRS;

b) Specificare il pubblico a cui è diretto l’SRS.

5.1.2 Scopi (1.2 del SRS)

Questa sottosezione deve

a) identificare il prodotto software da produrre con un nome (ad esempio, Host DBMS, Report Generator ecc.);

b) spiegare ciò che il prodotto software farà e, se necessario, non farà;

c) descrivere l’applicazione del software, inclusi benefici rilevanti, gli obiettivi;

d) dire se il prodotto è consistente con asserzioni differenti di alto-livello (ad esempio, le specifiche di requisiti di

sistema), se esistono;

5.1.3 Definizioni, acronimi e abbreviazioni (1.3 del SRS)

Questa sottosezione dovrebbe provvedere a definire tutti i termini, acronimi, e le abbreviazioni per poter interpretare

appropriatamente l’SRS. Queste informazioni possono essere provviste di referenza ad uno o più appendici nell’ SRS o

da referenza ad altri documenti.

5.1.4 Referenze (1.4 del SRS)

Questa sottosezione deve

a) prevedere un elenco completo di tutti i documenti esterni citati nell’SRS;

b) identificare ogni documento con titolo, numero di rapporto (se applicabile), data e organizzazione;

c) Specificare le fonti dalle quali possono essere ottenute le referenze.

Queste informazioni possono essere provviste da referenza ad un'appendice o ad un altro documento.

5.1.5 Veduta d'insieme (1.5 del SRS) Sommario

Questa sottosezione deve

a) descrivere quello che contiene il resto dell’ SRS;

b) Spiegare come l’SRS è organizzato.

5.2 Descrizione complessiva (Sezione 2 dell’ SRS)

Questa sezione dell’ SRS dovrebbe descrivere i fattori generali che incidono sul prodotto ed i suoi requisiti. Questa

sezione non contiene specifiche di requisiti. Invece, prevede un sfondo per requisiti che sono definiti in dettaglio in

Sezione 3 del SRS, e li rende più facile capire.

Questa sezione è costituita in genere di sei sottosezioni, come segue:

a) prospettiva di prodotto;

b) funzioni del prodotto;

c) caratteristiche dell’utente;

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

Traduzione del documento inglese fornito dalla prof. Fasolino

d) costrizioni;

e) assunzioni e dipendenze;

f) inserimento di requisiti

5.2.1 Prospettiva del prodotto (2.1 del SRS)

Questa sottosezione dell’SRS dovrebbe mettere il prodotto in confronti con gli altri prodotti riferiti. Se il prodotto è

indipendente dovrebbe essere affermato qui. Se l’SRS definisce che un prodotto è un componente di un più grande

sistema, come frequentemente accade, in questa sottosezione si dovrebbe riferire i requisiti di quel più grande sistema in

relazione alla funzionalità offerta dal software e dovrebbe identificare interfacce tra quel sistema ed il software.

Un diagramma a blocchi che mostra i componenti notevoli del più grande sistema, le interconnessioni, ed interfacce

esterne potrebbe essere particolarmente utile.

Questa sottosezione dovrebbe descrivere anche come il software opera sotto i vari vincoli. Per esempio, questi vincoli

potrebbero includere

a) interfacce di sistema;

b) interfacce di Utente;

c) interfacce di hardware;

d) interfacce di software;

e) interfacce di comunicazioni;

f) la Memoria;

g) le Operazioni;

h) requisiti di adattamento di ambiente.

5.2.1.1 Interfacce di sistema

Questo dovrebbe elencare ogni interfaccia del sistema e dovrebbe identificare la funzionalità del software per

completare il requisito di sistema e la descrizione dell'interfaccia per collegare il sistema.

5.2.1.2 Interfaccia di utente

Questo dovrebbe specificare:

a) Le caratteristiche logiche di ogni interfaccia tra il prodotto del software ed i suoi utenti.

Include quelle caratteristiche di configurazione (ad esempio, configurazioni dello schermo richieste, pagina o

configurazioni della finestra, contenuto di alcuni rapporti o menu, o la disponibilità di tasti di funzione programmabili)

necessarie a completare i requisiti del software.

b) Tutti gli aspetti per ottimizzare l'interfaccia con la persona che deve usare il sistema.

Questo può semplicemente comprendere un elenco di cosa fa o non fa il sistema qualora comunichi con l'utente. Un

esempio può essere un requisito per la scelta di messaggi d’errore lunghi o corti. Come tutti altri, questi requisiti devono

essere verificabili.

5.2.1.3 Interfaccia Hardware

Questo dovrebbe specificare le caratteristiche logiche di ogni interfaccia tra il prodotto software e l’hardware

componente del sistema. Questo include caratteristiche di configurazione (numero di porti, instrunction set, ecc.).

Descrive anche le apparecchiature di supporto, come esse saranno supportate, e i protocolli.

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


PAGINE

19

PESO

117.06 KB

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2013-2014

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher cecilialll di informazioni apprese con la frequenza delle lezioni di Fondamenti di informatica e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Fassolino Rita.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Fondamenti di informatica

Fondamenti di Informatica - von neumann e processore
Dispensa
Fondamenti di Informatica – Dispensa
Dispensa
Appunti di Fondamenti di Informatica
Appunto
Fondamenti di informatica - Esercitazioni
Esercitazione