Altri requisiti in un singolo caso: corretto?

1

Ho discusso con uno sviluppatore che insiste che 1 richiesta funzionale (FR) == 1 use case (UC). Penso che sia un'assurdità poiché ci sono requisiti che descrivono spesso situazioni derivanti dallo stesso punto - per questo i casi d'uso hanno flussi alternativi.

Ad esempio:

FR01 - User can log in
FR02 - User's account will be locked after 3 incorrect passwords.
FR03 - Logged user can log out

Credo che tutti questi possano essere ben catturati in un singolo caso, descrivendo l'interazione tra l'utente e il sistema.

Ma forse mi manca qualcosa?

EDIT: in base al libro "Use Case Modeling" di Bittner, Spence:

a use case contains a set of description of requirements, the requirements are presented in the form of narrative rather than an itemized list...

...
Quindi direi che sicuramente più requisiti possono essere catturati in un singolo caso.

    
posta KhDonen 16.07.2014 - 10:13
fonte

2 risposte

1

Un caso d'uso descrive un'interazione indipendente e completa eseguita dall'utente. Pensa a ciò che l'utente farà.

Un caso d'uso è descrittivo. Descrive la motivazione dell'utente, quale funzione serve, perché la funzione è importante, ecc. Non ha i requisiti funzionali "rigidi" usati in un PRD. Ma descrive lo stesso scenario con più contesto.

Quindi suddividilo in requisiti funzionali "duri". Sulla base dei tuoi esempi, penso che tu stia mescolando i due ambiti. Prendi l'esempio di un sito web di shopping:

UC 1: As a customer, I want to log in to the site so that I can save relevant data to my profile. This helps me to save time and effort by entering the data only once. I want my data to be secure and visible only to me.

FR 1.1: If user is already logged in, they should not be able to log in again

FR 1.2: If not logged in. a login screen should be shown

FR 1.3: If login is successful, ...

FR 1.4: If login is unsuccessful, show an error message.

FR 1.5: User's account will be locked after 3 incorrect passwords

e così via.

    
risposta data 16.07.2014 - 10:58
fonte
0

Non esiste una singola regola per governare la tua situazione. Esistono argomenti validi per un caso a uso singolo per tutti i requisiti e vi sono argomenti validi per rendere ogni funzione un caso d'uso. O va bene. Agile non parla della metodologia, ma del lavoro svolto.

Se puoi facilmente ottenere tutti i requisiti necessari in uno sprint e il lavoro può essere stimato con precisione, non è necessario scomporlo in storie separate. In effetti, si potrebbe obiettare che farlo rende più lavoro per il team, che non è sicuramente agile.

D'altra parte, se alcuni di questi requisiti sono difficili da implementare e alcuni sono facili, e alcuni si desidera entrare nelle mani degli utenti il prima possibile, rompere la storia renderà il tuo sprint più facile da gestire. Ciò comporterebbe la possibilità di fornire alcune di queste funzionalità più agevolmente, che sicuramente è agile.

L'obiettivo è portare a termine il lavoro. Se fare tutto questo lavoro come una singola storia ti avvicina di più a quell'obiettivo, fallo. Se si rendono separati i requisiti dei negozi, farlo.

Concentrati sul tuo vero obiettivo, ovvero fornire software di alta qualità.

    
risposta data 14.10.2014 - 13:05
fonte

Leggi altre domande sui tag