Le specifiche funzionali fanno parte delle specifiche dei requisiti di sistema?

Disambiguation

• Requisiti di sistema (utilizzati nell'ingegneria dei sistemi)

• Requisiti software (utilizzati nell'ingegneria del software)

Risposta principale

I requisiti di sistema delineano i requisiti per l'intero sistema. Un sistema è un insieme di hardware e software per supportare una specifica esigenza aziendale.

I requisiti software riguardano solo il software. Sono molto più dettagliati dei requisiti di sistema, in modo che il software possa essere effettivamente costruito da questi.

La Specifica dei requisiti del software (SRS) è uno standard: IEEE 830-1998 . I requisiti funzionali fanno parte di questo standard.

Specifiche funzionali è un documento separato che non è più utilizzato oggi (almeno in Ingegneria del software). Era uno standard nei periodi in cui la cascata veniva utilizzata come tecnica più nota e prima che la specifica dei requisiti del software IEEE diventasse uno standard. Lo SRS lo ha sostituito perché i requisiti funzionali sono ora definiti come parte di un documento più grande (requisiti software).

Nei periodi bui della crisi del software, credo che le specifiche funzionali fossero le migliori che conoscevano (senza tutti questi servizi che l'intero SRS ci offre). Pensavano che la specifica dei requisiti del software fosse solo una specifica delle funzioni richieste. Oggi sappiamo che c'è dell'altro. (vedi SRS)

Cronologia e uso corrente dell'SRS

Lo SRS è del 1998 e non era pensato per OOP. L'ho usato nella mia azienda, ma solo come base per la personalizzazione. Invece di descrivere i requisiti funzionali usando un linguaggio naturale, come il vecchio documento di specifiche funzionali, ho usato UML (usa diagrammi dei casi). Questo è qualcosa che non è stato ancora considerato nel 1998, quindi gli ingegneri hanno ancora descritto le esigenze in modo abbastanza inefficiente.

Conclusione

Le specifiche funzionali fanno parte del documento delle specifiche del software. Il documento è utile, ma non lo consiglierei di adottarlo così com'è perché è stato definito nel 1998; invece, suggerisco di considerare UML dove appropriato per sostituire le specifiche del linguaggio naturale.

Riferimenti

link

link

link

link

In genere, una specifica dei requisiti di sistema contiene i requisiti di livello superiore per un sistema. Un sistema è un insieme di sottosistemi software e / o hardware. In genere, questo include i requisiti funzionali e non funzionali (prestazioni, sicurezza, sicurezza, business, governance, regolamentazione e così via) per il sistema nel suo complesso. Ogni sottosistema nel sistema avrebbe anche una specifica dei requisiti, con le specifiche di un sottosistema software tipicamente chiamate specifiche dei requisiti del software. Ogni requisito specifico del sottosistema software è mappato su almeno un requisito nella specifica dei requisiti di sistema.

In alcuni progetti potrebbe esserci anche il concetto di requisiti del cliente o un concetto di operazioni. Questi sono in genere anche requisiti, ma forniti dal cliente nella lingua del dominio e potrebbero non essere adatti al consumo da parte degli ingegneri. Questi sono trasformati in requisiti di sistema da parte di ingegneri che comprendono le esigenze del cliente e dell'azienda.

Si noti che organizzazioni diverse possono avere nomi diversi per la stessa cosa o possono suddividere il contenuto in repository o documenti diversi. Esistono alcuni standard - l'IEEE ha un numero di standard relativi all'ingegneria dei sistemi e all'ingegneria del software, ad esempio - ma le organizzazioni potrebbero non seguire questi standard o personalizzarli per soddisfare meglio le loro esigenze.

Per ulteriori informazioni, potresti essere interessato a due libri di Karl Wiegers - Requisiti software e Ulteriori informazioni sui requisiti software .

Sono d'accordo con la tua interpretazione. Parlando in generale ...

Requisiti = Cosa dovrebbe fare?

Specifiche = Come dovrebbe essere?

Nonostante sia molto difficile, ritengo che questa regola empirica descriva abbastanza bene l'intento e la portata di questi documenti. I miei 2 centesimi ...

SRS definisce ampiamente i requisiti del cliente e descrive cosa ci si aspetta dal sistema. Le specifiche funzionali descrivono ulteriormente quali sono le funzioni attese dal dominio e dai sottodomini descritti in SRS. SRS è la base di ogni SDLC.

Un SRS è un documento preparato essenzialmente dal Business Analyst. Come hai detto, include obiettivi aziendali e requisiti di alto livello.

Considerando che un documento di specifiche funzionali comprende i dettagli delle finalità e dei processi dell'intero sistema ed è molto più approfondito. Questo documento è preparato in collegamento con il Software Engineer e System Anaylyst.

Per ulteriori informazioni visita i seguenti link:

Documento sulle specifiche funzionali

SRS