Business Rules integrazione User Stories

Question

ho una serie di user story e ho una serie di regole di business (principalmente leggi vincolanti le mie esigenze per essere compatibile). In Agile SDLC io non sono sicuro dove queste "regole" sono attaccati ai miei racconti degli utenti.

Per esempio, una storia come utente:

  

Come medico voglio aggiungere le informazioni del paziente, al fine di creare un nuovo file del paziente.

E una regola come:

  

Le seguenti informazioni devono essere inserite nel record di ogni paziente:     (un paziente:    (I) nome e cognome;    (Ii) l'indirizzo;    (Iii) la data di nascita; e    (Iv) il sesso;

I due si incontrano in modo chiaro, ma come posso creare un collegamento? Come le definizioni di test di accettazione nella mia storia utente? Un'altra storia utente?

Answer 1

Ci sono diversi modi che ho visto questo gestito:

1. è creato

   Un artefatto di tenere la regola di business e viene memorizzato in qualche archivio centrale di tutte le regole in modo tale è conosciuta in tutto il team di sviluppo e di un magazzino di conoscenze è mantenuta. Questo può ottenere brutto come ci possono essere centinaia di regole nel giro di pochi anni di costruzione di una domanda.

2. Le regole può essere messo su schede separate all'interno della storia dell'utente. Così, mentre la storia utente è che una linea, ci possono essere 6-8 carte che compongono tutti i compiti per quella storia da completare. Ad esempio, ci deve essere una nuova forma del paziente creato, convalida la forma, ecc Così, non è difficile vedere questa coltura su tutta la linea su una carta come un modo per monitorare la condizione in quel modo. Questo è il più naturale per la mia mente anche se questo non è dove l'elenco specifico sta per essere al 100% scritto sia come la carta potrebbe essere "assicurano alcuni campi del modulo sono obbligatori".

3. Non è un legame esplicito, ma piuttosto la regola è qualcosa per QA o di una laurea per nota per l'utente di verificare che il modulo fa rispettare questa regola. Questo è simile a uno, ma la domanda è che cosa è la responsabilità dello sviluppatore di questo. In questo caso, si tratta di qualcosa per QA per tenere traccia piuttosto che sviluppatori possibilmente.

La storia utente è destinato ad iniziare una discussione, non può essere un elenco completo dei requisiti. La regola è qualcosa che dovrebbe venire quando le discute di sviluppo con l'utente che cosa ci vuole per creare un nuovo file del paziente in mente.

---

Mi piace l'idea di appendere a schede per un paio di sprint dopo la storia è stato fatto, ma mi fanno vedere il punto che le carte saranno infine distrutti. Allo stesso tempo, ci dovrebbe essere da qualche parte di codice che implementa le regole nella sua area corretta. Per utilizzare l'esempio che hai postato, è possibile che in alcuni punti l'elenco dei campi obbligatori sarebbe stata notata in quanto v'è il livello di interfaccia utente che deve mostrare i campi e, probabilmente, un messaggio di errore, ma anche ci dovrebbe essere qualche strato Business Logic che ha questa logica di vedere che alcuni campi sono stati specificamente completati prima di provare a creare un nuovo file del paziente. Il sistema in fase di costruzione, ospiterà anche le regole in un modo o nell'altro, anche.

Answer 2

Come criteri di accettazione. Dopo tutte queste sono regole che possono essere eseguiti come test. Sicuramente non nuove storie, che sarebbe solo sbagliato in quanto non v'è alcun obiettivo consegnabile.