Facciamo sempre 2 documenti SRS (Software Requirement Specification) e FS (Functional Specifications) per i programmatori, ovvero i programmatori.
Come ho esaminato, il SRS è più simile al contenere sia i requisiti funzionali che quelli non funzionali rispetto al FS che si occupa solo dei requisiti funzionali.
Per farla breve, l'SRS sarà sufficiente per consentire ai programmatori di fare il loro lavoro? e non fai più FS?
Dipende probabilmente dalla tua organizzazione e dalle dimensioni del tuo prodotto, ma penserei che più volte gli input dei clienti e degli ingegneri di sistema vengono convertiti da una forma all'altra, più costoso è il tuo prodotto e forse più seriamente, più disconnessi saranno gli sviluppatori relativi al cliente.
Distinguere tra requisiti funzionali e di sistema probabilmente ha alcuni vantaggi, ma penso che la nostra documentazione debba per lo più crescere verticalmente (più descrittiva) piuttosto che orizzontale (cascata più grande, più handoff). Anche i grandi progetti DoD si stanno organizzando in approcci sistemici di sistema in modo che possano essere realizzati con team più piccoli, specifiche più piccole, budget minori e un potenziale di riutilizzo più elevato.
Un'altra considerazione potrebbe essere se si utilizza il modello V. Nel modello V, esiste un ciclo delle specifiche del cliente che si accoppia con i test di accettazione, la progettazione che si accoppia con i test di integrazione del sistema e lo sviluppo che si accoppia con il test delle unità. Se i tuoi due documenti di requisiti non si allineano con la creazione di casi di test, ciò potrebbe portare a qualche patologia. Ad esempio, si dispone di requisiti in cui nessun caso di test corrispondente impone l'interpretariato deve essere interpretato concretamente (ad esempio, il sistema deve avere prestazioni superiori significa nulla, ma il sistema deve rispondere a presse touch screen entro 200 ms e può essere testato ), quindi si può finire con reali disaccordi sull'adeguatezza e la deliverability del prodotto.
La duplicazione nei tuoi documenti è un problema di dati. Le visualizzazioni dei dati vengono trattate come origini dati. DB relazionali, normalizzazione e query sono stati progettati per gestire questo. Potrebbe essere over-kill, ma potresti creare un database dei requisiti. Una query filtrata produrrebbe i requisiti "funzionali".
Forse un foglio Excel con una colonna flag funzionale / non funzionale sarebbe sufficiente.
Finché i programmatori e il QA concordano che questo è sufficiente e sei felice che ciò che viene consegnato e non spenda troppo tempo dopo spiegando le funzionalità a dev / QA - Non credo che la gente si preoccuperà di quale sia il documento chiamato. Non c'è motivo di avere due documenti che sono in gran parte duplicati l'uno dell'altro.
Dovrai identificare quali requisiti in SRS sono riconducibili alle funzionalità (quando l'utente fa clic su A, B succede) e quali non lo sono (ad esempio estensibilità, costo) in modo da poter ottenere un accordo sul fatto che il software soddisfi i requisiti quando tutto viene detto e fatto .
Leggi altre domande sui tag project-management