Ci sono molti modi in cui le cose possono essere strutturate, ma questa è una presa su di essa:
-
Specifiche dei requisiti di sistema (SyRS): questo è il documento di ingegneria di alto livello che enumera i requisiti su come il sistema deve funzionare. È non un documento solo software; se il sistema include hardware o più componenti software, li descrive anche.
-
Specifiche dei requisiti software (SwRS): questa è una descrizione completa dei requisiti di un singolo componente software.
Ciascuno di questi due documenti potrebbe essere definito una "specifica funzionale". Dipende dalla portata di ciò di cui stai parlando.
UPDATE : in genere, il SyRS deve contenere solo i requisiti / le specifiche funzionali applicabili al sistema nel suo complesso. Un SyRS greenfield non decide quale sia l'architettura del sistema; questo è per il documento di progettazione.
Il documento di progettazione (chiamalo Documento di architettura di sistema, SyAD ) decide quali componenti software sono richiesti e come si interfacciano tra loro.
Lo SwRS per ogni componente definito è quindi una specifica funzionale molto più dettagliata di come funziona ogni singolo componente.
A volte, per garantire la coerenza dell'interfaccia utente, ad esempio, è opportuno raggruppare i requisiti comuni in SyRS.
Ciò può creare confusione, ma il piano di test e i casi di test per ciascun componente software dovrebbero estrarre le specifiche appropriate dai luoghi appropriati.
Strumenti di gestione dei requisiti come DOORS consentono il cross-linking tra i documenti dei requisiti (e la tracciabilità dall'ideazione del prodotto alla consegna finale).
Does Functional Requirement Specification talk about system design?
No, dovrebbe essere gestito da un documento di progettazione.
should there be a single system requirements document and individual SRS for all the applications?
Sì, sembra un buon modo per procedere.
I also assume that functional requirements strictly deals only with requirements and not the design
Sì, i due sono distinti, ma le persone spesso li confondono.
Could each line of a pseudo code be defined as functional requirement eg: System B must pass emp id , name to System C on receipt of request from System A.
L'esempio che citi sicuramente sembra un requisito funzionale a livello di sistema. Basta fare attenzione non per includere nel SyRS qualcosa del tipo "e emp id deve essere nella forma di un GUID". L'unico motivo per includere dettagli tecnici come quello in un SyRS è se c'è qualche vincolo sul sistema (come tutti gli ID emp in entrata o pre-esistenti sono GUID).
Da dove provengo è l'approccio all'ingegneria dei sistemi chiamato "design V" (a volte il design W). Vedi Wikipedia per ulteriori , anche se in un mondo "Agile" alcuni di questi vengono dimenticati.
