Requisiti software

Traduzione del documento inglese fornito dalla prof. Fasolino

IEEE - Procedura Raccomandata per le Specifiche dei Requisiti Software

Sponsor

Software Engineering Standards Committee of the IEEE Computer Society

Approvato il 25 giugno 1998

IEEE-SA Standards Boards

Sommario: il contenuto e le qualità di una buona specifica dei requisiti software (SRS, Software Requirements

Specifications) sono descritte e esemplificate nel modelli standard di SRS. Questa procedura guidata è diretta a

specificare i requisiti del software che deve essere sviluppato ma può anche essere applicato all’aiuto nella scelta dei

prodotti del software commerciale o aziendale. I vari punti del documento seguono l’IEEE/EIA 1220.1-1997.

Parole chiave: contratto, prototipizzazione, cliente, specifica dei requisiti sofware, fornitore, specifiche dei requisiti di

sistema.

I documenti IEEE standard sono sviluppati attraverso le società e i comitati IEE dell’Associazione IEEE Standard

(IEEE-SA). I membri di tale comitato perseguono volontariamente senza compensi. Essi non sono necessariamente

membri dell’Istituto. Gli standards sviluppati attraverso l’IEEE rappresentano un consenso di un gran numero di esperti

dell’argomento. L’uso di uno standard IEEE è assolutamente volontario. L’esistenza di un IEEE Standard non implica

che non ci debbano essere altre strade per produrre testi, misure, prodotti, scopi o altri servizi che la stessa IEEE intende

raggiungere. Anche lo stesso standard IEEE è soggetto a revisione e modifica ogni 5 anni. Quando un documento ha +

di 5 anni e non è stato rivalutato, è ragionevole pensare che il suo contenuto, a scapito di qualche suo punto, non

rappresenta più l’attuale stato. Gli utenti sono costretti a cercare di determinare che essi hanno l’edizione più vecchia di

qualche standard IEEE.

I commenti per la revisione degli standard è ben accettata attraverso commenti, relazioni, discussioni di tutti le affiliatr

società all’IEEE. I commenti e le modifiche vengono segnalate in documenti sotto forma di testo con appropriato

commento di supporto.

Interpretazioni: occasionalmente le domande possono riguardare il significato di porzioni di standards relative a

specifiche applicazioni. Quando l’IEEE deve effettuare tale interpretazione in base alle richieste, l’Istituto prevede

apposite risposte.

Introduzione

(Questa introduzione non fa parte dell’IEEE Std 830-1998, IEEE Recommented Practice for Software Requirements

Specifications)

Questa procedura guidata descrive l’approccio da seguire per le specifiche dei requisiti del software. Essa è basata su un

modello in cui il risultato del processo di specifica dei requisiti software è un documento di specifica non ambiguo e

completo. Esso aiuta:

a) I clienti software per descrivere accuratamente ciò che loro vogliono ottenere;

b) Gli sviluppatori (fornitori) software per capire esattamente cosa il cliente vuole;

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

Traduzione del documento inglese fornito dalla prof. Fasolino

c) I singoli per raggiungere i seguenti obiettivi: 1) sviluppo di righe di specifica dei requisiti software (SRS) per

le diverse organizzazioni; 2) definire il formato e il contenuto delle specifiche dei requisiti software; 3)

sviluppare addizionali temi di supporto locale quale una checklist di qualità SRS, o un manuale utente SRS.

Al cliente, sviluppatore e altri individui, un bene del SRS è quello di fornire una seria di benefici, come segue:

- stabilire la base per un accordo tra cliente e sviluppatore su ciò che il software dovrà fare: la completa

descrizione delle funzioni del software specificata nell’SRS assiste i potenziali utenti a determinare se il

software fa ciò che essi desiderano o come il software possa essere modificato per andare incontro ai loro

interessi;

- ridurre lo sforzo nello sviluppo: la preparazione di un SRS forza i vari gruppi interessati nelle organizzazioni

dei clienti a considerare rigorosamente tutti i requisiti prima di progettare. Rilevare i problemi prima è meglio

di doverli correggere alla fine.

- Prevedere una base per stimare costi e organizzazione: la descrizione dei prodotti nell’SRS è una base

realistica per stimare i costi del progetto e può essere usata per ottenere statistiche sulla vendita.

- Prevedere una base per la validazione e la verifica: nell’SRS ci può essere anche la parte di validazione e

verifica.

- Trasferimento facilitato: L’SRS porta facilmente a trasferire il prodotto software ad un nuovo utente o una

nuova macchina.

IEEE RECOMMENDED PRACTICE FOR SOFTWARE REQUIREMENTS SPECIFICATIONS

1. Premessa

Questo approccio guidato descrive le raccomandazioni da seguire per la specifica dei requisiti software. Esso è diviso in

5 parti. La prima clausola spiega lo scopo di questa procedura guidata. La seconda clausola lista i riferimenti ad altri

standard. La terza clausola prevede le definizioni di termini specifici usati. La quarta clausola prevede informazioni di

fondo per scrivere un buon SRS. La quinta clausola discute ognuna delle parti essenziali di un SRS. Questo procedura

guidata ha anche due appendici, una in cui ci sono templates in formato alternativo e uno che prevede un documento

che segue lo standard IEEE/EIA 12207.1-1997.

1.1 Scopo

Questa è la procedura guidata per scrivere le specifiche dei requisiti software. Essa descrive il contenuto e la qualità di

un buon SRS e presenta alcuni esempi di righe SRS.

Questa procedura cerca di specificare i requisiti di un software da sviluppare ma può anche essere applicato per aiutare

nella selezione di prodotti commerciali. Tuttavia, le applicazioni fornite nel software potrebbero essere

controproducenti.

Quando il software è implementato in molti sistemi, come apparecchi ospedalieri, tutte le raccomandazioni devono

essere seguite alla lettera.

La procedura guidata descrive il processo di creazione di un prodotto e il contenuto del prodotto. Il prodotto è un SRS.

La procedura serve o a creare direttamente un SRS o per essere presa da modello per altri specifici standard.

Questa procedura guidata non identifica uno specifico metodo, nomenclatura o strumento per la preparazione di un

SRS.

2. Riferimenti

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

Traduzione del documento inglese fornito dalla prof. Fasolino

Qui ci vanno tutti i riferimenti ad altri standard

3. Definizioni

In generale le definizioni dei termini usati in questa procedura guidata sono conformi allo standard IEEE 610.12-1990.

Le definizioni sottoindicate sono parole chiave come essi sono usati nella procedura stessa.

3.1 Contratto: un documento di accordo legale stipulato tra un fornitore e un cliente. Esso include i requisiti tecnici e

organizzativi, i costi, la schedulazione di un prodotto. Un contratto può anche contenere informazioni sui committenti

coinvolti.

3.2 Cliente: la persona, o persone, che pagano per il prodotto e solitamente (ma non necessariamente) decidono i

requisiti. Nel contesto di questa procedura guidata il cliente e lo sviluppatore possono essere membri della stessa

organizzazione.

3.3 Sviluppatore: la persona, o le persone, che producono un prodotto per un cliente. Nel contesto di questa procedura

guidata, il cliente e lo sviluppatore possono essere membri della stessa organizzazione.

3.4 Utente: la persona, o le persone, che operano e interagiscono direttamente con il prodotto. Gli utenti e i clienti non

sono spesso la stessa persona.

4. CONSIDERAZIONI PER PRODURRE UN BUON SRS

Questa clausola prevede informazioni di fondo che dovrebbero essere considerate quando si scrive un SRS. Questo

include i seguenti punti:

1) Natura dell’SRS;

2) L’ambiente dell’SRS;

3) Le caratteristiche di un buon SRS:

4) La articolata preparazione dell’SRS;

5) Prototipizzazione;

6) Implementazione di progetto nell’SRS;

7) Implementazione dei requisiti di progetto nell’SRS.

4.1 Natura dell’SRS

L’SRS è una specifica per un particolare prodotto software, programma o seti di programmi che implementano

particolari funzioni in uno specifico ambiente. L’SRS può essere scritto da uno o più rappresentanti degli sviluppatori,

uno o più rappresentanti dei clienti o da entrambi. Questi sono le proprietà che deve garantire chi scrive un SRS:

- funzionalità: cosa il software deve fare?

- Interfaccia esterna: cosa l’interfaccia software fa con gli utenti, il sistema hardware e altri hardware e altri

software?

- Performance: che velocità, tempo di risposta, efficienza e tempo di ritardo hanno le varie funzionalità del

software, ecc?

- Attributi: qual è la portabilità, la correttezza, la sicurezza, la manutenzione, ecc?

- Costanti di progetto imposte su una implementazione: ci sono requisiti standard nell’implementazione del

linguaggio, nelle politiche per l’integrità di database, limiti di risorsa, sistemi operativi, ecc.?

Colui che scrive l’SRS può scegliere altri modelli o specifiche per redarre l’SRS.

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

Traduzione del documento inglese fornito dalla prof. Fasolino

4.2 Ambiente di un SRS

E’ importante considerare la parte che un SRS gioca in un piano progettuale totale, che è definito nel IEEE Std

610.12-1990. Il software può contenere essenzialmente tutte le funzionalità di un progetto o può essere parte di un

più vasto sistema. Nell’ultimo caso tipicamente sarà un SRS che descrive le interfacce tra il sistema e la sua

porzione di software, con le performance esterne e requisiti funzionali sotto la porzione di software. Sicuramente

l’SRS dovrà essere arricchito con i requisiti del sistema.

IEEE Std 1074-1997 descrive i punti nel ciclo di vita del software e degli input applicabili per ogni punto. Altri

standards, come quelli elencati nella clausola 2, si riferiscono ad altre fasi del ciclo di vita del software ed in modo

da possono complementare i requisiti del software. Poiché lo SRS ha uno specifico il ruolo nel processo di sviluppo

del software, il writer dell’ SRS dovrebbe fare attenzione non andare oltre i limiti di quel ruolo. Ciò significa che lo

SRS a) dovrebbe correttamente definire tutto dei requisiti del software. Un requisito del software può esistere a

causa della natura dell'operazione da risolvere o a causa di una caratteristica speciale del progetto. b) Se descrivono

tutti i particolari di esecuzione o di progetto. Questi dovrebbero essere descritti nella fase di design del progetto. c)

Se impongono i vincoli supplementari al software. Questi sono correttamente specificati in altri documenti come un

programma di garanzia della qualità del software. Di conseguenza, un SRS correttamente scritto limita la gamma di

design validi, ma non specifica alcun design particolare.

4.3 Caratteristiche di un buon SRS

Un SRS deve essere:

1) corretto;

2) non ambiguo;

3) completo;

4) consistente;

5) allineato per importanza e/o stabilità;

6) modificabile;

7) tracciabile.

4.3.1 Corretto

Un SRS è corretto se e soltanto se, ogni requisito dichiarato in esso è uno stato rispettato dal software. Non c’è

strumento o procedura che accerti la precisione. Lo SRS dovrebbe essere paragonato a tutte le specifiche superiori

applicabili, come una specifica di requisiti del sistema, ad un’altra documentazione di progetto e ad altri standard

applicabili, per accertarsi che sia stata ben sviluppato. Alternativamente il cliente o l'utente può determinare se i

requisiti di SRS riflettano correttamente i bisogni reali. La tracciabilità rende questa procedura più facile e meno incline

all'errore (veda 4.3.8).

4.3.2 Non ambiguo

Un SRS è non ambiguo se e solo se ogni requisito in esso presente ha una sola interpretazione. Come minimo, ciò

significa che ogni caratteristica del prodotto finale sia descritta usando un singolo termine univoco.

Nei casi in cui un termine usato in un contesto particolare potesse avere significati multipli, il termine dovrebbe essere

incluso in un glossario in cui il relativo significato è reso più specifico. Un SRS è una parte importante del processo di

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

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 &egr