Pochi problemi riguardanti le fasi SDLC e SRS

0

Sto lavorando nel piccolo settore IT e stiamo cercando di implementare processi e SDLC nella nostra organizzazione, dato che siamo in fase iniziale ho poche preoccupazioni e quindi voglio un consulente di esperti qui:

  • Attualmente creiamo 1 documenti SDLC principali: SRS.

  • SRS viene inizialmente creato dai nostri dirigenti di sviluppo aziendale che sono il primo POC con il cliente ogni volta che entra in gioco qualsiasi requisito. Creano un documento SRS approssimativo con tutti i requisiti del client.

  • Una volta che i requisiti sono congelati, SRS viene passato al Project Manager che fornisce il documento secondo i requisiti specificati dai dirigenti dello sviluppo aziendale.

Le mie preoccupazioni:

  • È questo il modo corretto in cui stiamo seguendo, se no, per favore suggerisci il modo corretto.

  • Lo SRS dovrebbe essere preparato solo dopo aver bloccato i requisiti?

  • Se sì, allora quale documento deve essere preparato dai dirigenti dello sviluppo aziendale che stanno ancora raccogliendo i requisiti dei clienti.

posta 19.11.2015 - 13:15
fonte

1 risposta

2

Non mi piace che i tuoi requisiti sembrino vivere in un documento di specifica dei requisiti del software anziché uno strumento di gestione dei requisiti. Un approccio basato su documenti rende più difficile acquisire la tracciabilità tra i requisiti e riutilizzare i requisiti di progetti o prodotti in una linea di prodotti software. Questi potrebbero non essere necessariamente problemi per te in questo momento, ma sarebbe più facile iniziare con uno strumento di gestione dei requisiti piuttosto che provare a gestire i documenti e quindi importare diversi documenti in uno strumento e rimuovere la duplicazione e gestire la tracciabilità dopo il fatto.

Forse è implicito, ma il processo che descrivi non ha alcun tipo di iterazione sui requisiti. Quando i requisiti iniziali del cliente arrivano dai dirigenti dello sviluppo del business, probabilmente non saranno adatti per eseguire attività di progettazione, implementazione e test. Almeno alcuni dei requisiti dovranno essere chiariti e riscritti. Inoltre, ci saranno probabilmente altri requisiti che provengono da altre fonti: il team di test potrebbe introdurre requisiti di testabilità che è necessario implementare, potrebbero esserci requisiti aziendali o normativi che influiscono sul prodotto. Questi dovranno anche essere catturati nello SRS e rivisti con il cliente per assicurarsi che comprendano e possano convivere con tali requisiti.

Il concetto di congelamento di un SRS è un po 'strano per me. Anche in un processo sequenziale, il cliente potrebbe voler cambiare i requisiti. Vi è un impatto sui costi e sulla pianificazione associato a una modifica dei requisiti (specialmente in un processo sequenziale), ma il processo per ricevere una richiesta di modifica, valutare la richiesta e determinare una risposta e una disposizione dovrebbe probabilmente essere qualcosa che si desidera definire.

Se desideri ulteriori indicazioni su come lavorare con i requisiti software e sviluppare un approccio, ti consiglio vivamente di ottenere una copia del Software Requisiti (terza edizione) di Karl Wiegers e Joy Beatty . Potrebbe anche essere utile una copia di IEEE Standard 29148-2011 .

    
risposta data 19.11.2015 - 14:39
fonte

Leggi altre domande sui tag