Scrivere una specifica dei requisiti software


15

Ho alcune domande su come scrivere una specifica e sono:

  1. Quando scriviamo una specifica software, nell'argomento "Definizione requisiti utente" dobbiamo specificare solo le "Funzioni" e "Vincoli"?

  2. "Interfaccia utente" rientra in "funzioni" o "vincoli"?

  3. Quali sono le principali aree chiave (requisiti) in cui un software può essere suddiviso (es. UI)?


Questo articolo può essere utile: 10 errori tipici nelle specifiche
yegor256

Risposte:


16

Anche se non sono un grande fan di raccogliere tutti i requisiti in dettaglio (poiché sono soggetti a così tanti cambiamenti nel corso di un progetto non banale), se stai scrivendo documenti sui requisiti, il modello di specifica dei requisiti Volere è una guida eccellente .

Anche se può essere eccessivo per alcuni progetti, fornisce una grande lista di cose su cui pensare, anche se è solo per controllare mentalmente l'elenco che non hai bisogno di quell'elemento per questo requisito.

Ecco un link per ulteriori informazioni sul modello:

http://www.volere.co.uk/template.htm

Il modello stesso (e il libro Mastering the Requirements Process - che in realtà è leggermente meno costoso del modello e contiene il testo completo del modello) contiene molte informazioni, esempi e consigli all'interno delle varie sezioni su cosa dovrebbe andare in ogni sezione.

Ecco un riepilogo delle sezioni in esso contenute (citate dal link sopra):

  1. Lo scopo del progetto

  2. Gli stakeholder

  3. Vincoli obbligatori

  4. Convenzioni e definizioni di denominazione

  5. Fatti e ipotesi pertinenti

  6. Lo scopo del lavoro

  7. Modello di dati aziendali e dizionario dei dati

  8. Lo scopo del prodotto

  9. Requisiti funzionali e di dati

  10. Aspetto e requisiti

  11. Requisiti di usabilità e umanità

  12. Requisiti di prestazione

  13. Requisiti operativi e ambientali

  14. Requisiti di manutenzione e supporto

  15. Requisiti di sicurezza

  16. Requisiti culturali e politici

  17. Requisiti legali

  18. Questioni aperte

  19. Soluzioni pronti all'uso

  20. Nuovi problemi

  21. Compiti

  22. Migrazione al nuovo prodotto

  23. rischi

  24. Costi

  25. Documentazione e formazione dell'utente

  26. Sala d'attesa

  27. Idee per soluzioni


10

Consiglio di leggere Joel sul software. Non sono sicuro che risponda alle tue domande specifiche, ma ha un'eccellente panoramica di ciò che significa scrivere specifiche funzionali :

La funzione più importante di una specifica è progettare il programma . Anche se stai lavorando sul codice da solo e scrivi una specifica esclusivamente a tuo vantaggio, l'atto di scrivere la specifica - descrivendo come funziona il programma in dettaglio, ti costringerà a progettare il programma ...

... quando progetti il ​​tuo prodotto in un linguaggio umano, ci vogliono solo pochi minuti per provare a pensare a diverse possibilità, a rivedere e migliorare il tuo design. Nessuno si sente male quando elimina un paragrafo in un elaboratore di testi. Ma quando progetti il ​​tuo prodotto in un linguaggio di programmazione, ci vogliono settimane per fare progetti iterativi. Quel che è peggio, un programmatore che ha appena trascorso 2 settimane a scrivere del codice sarà abbastanza attaccato a quel codice, non importa quanto sia sbagliato ...

... Quando scrivi una specifica, devi solo comunicare come dovrebbe funzionare il programma una volta . Tutti nel team possono solo leggere le specifiche. Gli addetti al QA lo leggono in modo da sapere come dovrebbe funzionare il programma e sapere per cosa testare. Gli addetti al marketing lo usano per scrivere i loro vaghi white paper sul vaporware da vomitare sul sito web sui prodotti che non sono ancora stati creati. Le persone che si occupano dello sviluppo del business lo hanno letto male per far girare strane fantasie su come il prodotto curerà la calvizie, le verruche e le cose, ma attirerà gli investitori, quindi va bene. Gli sviluppatori lo hanno letto in modo da sapere quale codice scrivere. I clienti lo hanno letto per assicurarsi che gli sviluppatori stessero costruendo un prodotto per il quale avrebbero voluto pagare. Gli scrittori tecnici lo leggono e scrivono un bel manuale ...

Quando non si dispone di una specifica, tutte queste comunicazioni continuano, perché è necessario , ma avviene ad hoc . La gente del QA si scherza con il programma, volenti o nolenti, e quando qualcosa sembra strano, vanno e interrompono ancora una volta i programmatori per chiedere loro un altro stupida domanda su come dovrebbe funzionare la cosa ...

senza una specifica dettagliata, è impossibile fare un programma ... In troppe organizzazioni di programmazione, ogni volta che c'è un dibattito sul design, nessuno riesce mai a prendere una decisione, di solito per motivi politici. Quindi i programmatori lavorano solo su cose non controverse. Col passare del tempo, tutte le decisioni difficili vengono spinte alla fine ... Scrivere una specifica è un ottimo modo per inchiodare tutte quelle fastidiose decisioni di progettazione, grandi e piccole, che vengono nascoste se non si dispone di una specifica. ..


@gnat Non credo sia necessaria la citazione dall'articolo. Se desideri evidenziare la tua scelta di brani, ti suggerisco di pubblicare la tua risposta alla domanda.
Jonathan Swinney,

considera di dare una lettura alla tua risposta è in un altro castello: quando una risposta non è una risposta? "Sia chiaro: questo tipo di risposta non è una risposta . Se vedi questo, segnalalo. I moderatori, se lo vedi contrassegnato, cancellalo "
moscerino

1
Se non sei d'accordo con gli estratti citati, non esitare a modificarli. Tuttavia, avere una risposta che è solo un collegamento non è considerata una buona risposta ed è soggetta alla cancellazione in base alle nostre politiche sulla qualità. Un post che fa riferimento a una risorsa o riferimento fuori sede dovrebbe fornire informazioni sufficienti per continuare ad aggiungere valore se il collegamento non è accessibile per qualsiasi motivo.
Thomas Owens

6

Quando scriviamo una specifica software, nell'argomento "Definizione requisiti utente" dobbiamo specificare solo le "Funzioni" e "Vincoli"?

Un requisito è una combinazione di due cose ...

  1. Cosa fa la cosa. Requisito funzionale
  2. Quanto bene lo fa. Requisito non funzionale o "Vincolo"

"Interfaccia utente" rientra in "funzioni" o "vincoli"?

Direi che "User Interface" sarebbe una categoria di requisiti come hai identificato nella tua ultima domanda.

Quali sono le principali aree chiave (requisiti) in cui un software può essere suddiviso (es. UI)?

Dipende dal software. È possibile raggruppare i requisiti in base a parti del sistema oppure raggrupparli in base al caso d'uso o ai requisiti aziendali che le funzioni soddisfano.

Ovviamente tutto ciò è secondario rispetto al tuo obiettivo reale che è quello di determinare una descrizione chiara, inequivocabile e verificabile del sistema software.


4

Il requisito principale per un requisito è che è testabile. Se non riesci a capire come testare un requisito, le probabilità sono che non verrà implementato nel modo previsto dallo scrittore.

Non ho mai visto un documento di requisiti limitato solo a Funzioni e Vincoli, ma posso vedere un valore nell'avere una struttura come questa: costringe lo scrittore a classificare i requisiti in "cose ​​che il software deve fare" e "governa il il software deve seguire ".

Penso che un'interfaccia utente abbia requisiti in entrambe le categorie

vincoli:

  • "la schermata di avvio mostrerà due pulsanti:" Start "e" Stop "
  • "Il carattere di visualizzazione non deve essere inferiore a 10 punti."

funzioni:

  • "Quando Startsi preme il tasto, il software deve stabilire una connessione TCP / IP a WOPR "

I tuoi esempi non sono requisiti, sono design. I dettagli su come realizzare il requisito è una decisione di progettazione, non un requisito. Pertanto, "due pulsanti" è una decisione di progettazione. Diventa ovvio quando ti rendi conto che ci sono molti altri modi validi per raggiungere lo stesso obiettivo (Start o Stop qualcosa). Pertanto, per renderlo più un requisito, diresti "L'interfaccia utente deve fornire un mezzo per avviare e interrompere qualcosa". Ma andrei oltre, perché l'utilizzo di un'interfaccia utente è anche una decisione di progettazione. Quindi per il requisito di sistema sarebbe "Il sistema deve fornire un mezzo per avviare e arrestare qualcosa"
Dunk
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.