Requisiti, utente o prospettiva del sistema?

0

Come identificare quando utilizzare un utente o una definizione di sistema di un requisito?

Nell'esempio seguente:

Use case: List Posts by status

Pre-conditions: The admin is authenticated. There are items registered in the system.

Trigger: The admin wants to list the posts according to its status (published, draft)

Ator: Admin

Main flow:

  • The system presents the saved posts and all the list options (published, drafft)

  • The admin chooses a list option

  • the system list the posts according to the list option chosen by the admin

Post-condition:

  • Posts listed according to the status chosen by the admin.

I requisiti funzionali sono:

  • il sistema deve presentare tutti i post registrati all'amministratore quando accede alla pagina di amministrazione dei post.

  • Il sistema deve elencare i post in base allo stato scelto dall'amministratore.

  • Il sistema deve presentare un messaggio informativo all'amministratore se non ci sono post registrati.

  • Il sistema deve solo elencare i post se l'amministratore ha effettuato l'accesso.

o

  • l'amministratore deve essere in grado di consultare tutti i post registrati quando accede alla pagina di amministrazione dei post.

  • L'amministratore deve essere in grado di elencare i post in base al suo stato.

  • L'amministratore deve essere informato se non ci sono post registrati.

  • L'amministratore deve effettuare l'accesso per controllare tutti i post registrati.

O nessuno? O è uguale?

    
posta OZy 06.06.2017 - 14:06
fonte

1 risposta

0

Documentare tutto come X deve essere eccessivamente formale e non umano, è facile perdere i requisiti di implementazione o non scoprire ipotesi che dovrebbero essere richieste. Sono un fan dell'uso della sintassi di stile Gherkin per documentare i requisiti, sia che tu lo usi per sviluppare test automatici o no . La sintassi Given, When, Then ti offre alcuni buoni bonus.

  • I suoi requisiti di facile lettura documentati in questo modo.
  • Diventa ovvio quando si tenta di documentare troppo con una singola istruzione.
  • Ti fa riflettere sul modo in cui il sistema dovrebbe comportarsi che può aiutare a scoprire i requisiti mancanti o le aree che necessitano di chiarimenti.
  • I requisiti vengono scritti come criteri di accettazione.
  • puoi utilizzarli insieme ai test automatici per essere più sicuro di aver implementato correttamente tutti i requisiti e le modifiche non hanno compromesso la funzionalità esistente.

Se devi documentare i requisiti in base alla tua domanda a causa di decisioni al di fuori del tuo controllo, allora non importa ciò che scegli. Scegliere in qualsiasi modo rende le persone felici che vogliono documenti come questo, entrambe le opzioni sono ugualmente irrilevanti.

    
risposta data 06.06.2017 - 15:34
fonte

Leggi altre domande sui tag