Esempi di raccolta richieste e casi d'uso [chiuso]

0

Ho sentito parlare molto della raccolta dei requisiti e dei casi d'uso in teoria, ma in pratica spesso accade che ci chiediamo "dovremmo includere questo? Se questo dovesse essere un caso d'uso? in quale lingua dovremmo scrivere questo particolare requisito?" e così via. Queste domande sono principalmente a causa della mancanza di pratica, e dal momento che non possiamo andare a raccogliere progetti per "imparare nella pratica" è un po 'difficile abituarsi al tipo di pensiero di cui abbiamo bisogno nel processo di raccolta dei requisiti per una nuova app. / p>

In questo caso, c'è un posto dove posso trovare esempi di vita reale di raccolta dei requisiti e applicazione dei casi d'uso? Ho trovato alcuni libri, ma sono principalmente incentrati sui team e lavoro da solo, quindi diventa un po 'confuso.

    
posta user1620696 14.11.2013 - 01:22
fonte

3 risposte

1

Un semplice esempio. Assistete un utente che testa il vostro prodotto di e-commerce. Ad un certo punto, l'utente desidera ottenere che ogni prodotto corrisponda a determinati tag all'interno di una fascia di prezzo. Attualmente, questo è impossibile, perché il prodotto consente di filtrare i prodotti per tag o filtrare i prodotti in base al prezzo, ma non entrambi contemporaneamente.

L'esigenza degli utenti sarebbe:

I want to filter products by tags and prices. How do I do it?

Trasformato in una user story, diventerebbe:

As a user, I should be able to filter the list of products using both tags and prices criteria.

Da quel punto, puoi studiare le implicazioni della nuova modifica e iniziare a scrivere test e implementare la nuova funzionalità.

    
risposta data 14.11.2013 - 08:34
fonte
1

In pratica, la raccolta dei requisiti dovrebbe avvenire prima e poi seguita da casi d'uso (e potresti avere un ciclo di feedback per verificare i requisiti). Il caso che descrivi di " dovremmo includere questo ", " dovrebbe essere un caso d'uso " si presenta principalmente negli ambienti di sviluppo del prodotto. Fare questa scelta è complicato in base alla tua voglia di rischio e alla tua squadra.

Se tuttavia stai cercando di sviluppare una soluzione per un cliente, la domanda è " Il client ha bisogno di questo " e niente di più. Potresti incontrare situazioni in cui il cliente non sa davvero di cosa ha bisogno, in tal caso ti consiglierei di andare ancora più in profondità e capire il problema aziendale che deve essere risolto. Una volta che è chiaro, la soluzione tecnica può seguire. In tali scenari di solito raccomanderei brevi iterazioni e una soluzione incrementale con partecipazione attiva del cliente.

In which language should we write this particular requirement

Stai insinuando un linguaggio di programmazione? In quel caso è sicuramente la domanda sbagliata da chiedere durante la raccolta dei requisiti. L'implementazione tecnica viene in genere decisa molto dopo durante la fase di raccolta dei requisiti.
Per prima cosa dovrebbe esserci una soluzione tecnica come dire una web-app, mobile-app, middleware, integrazione, soluzione db etc.
Potresti avere dei suggerimenti in merito all'argomento se il tuo cliente ha un negozio .net o java shop o si occupa di un determinato fornitore o, peggio ancora, è bloccato dal fornitore. Anche in questo caso la prima cosa dovrebbe essere la soluzione tecnica e in base a tempo / budget / risorse / condizioni diverse l'evoluzione tecnica si evolverà.

Sfortunatamente i libri possono solo suggerire vari scenari, e il migliore apprendimento è in pratica.

    
risposta data 14.11.2013 - 10:07
fonte
0

Ottieni casi d'uso dai tuoi utenti o dai tuoi clienti.

Essenzialmente, guidano i criteri di accettazione.

Senza parlare con utenti o clienti possiamo pensare a molti possibili usi (modelli) del nostro software, ma sono gli utenti o i clienti che dovrebbero dirci quali sono le chiavi.

D'altra parte, gli utenti troveranno spesso modi di usare il nostro software che non avevamo mai considerato e che trovano bug nel processo. Questo è il modo in cui il software di successo si evolve e genera nuovi requisiti.

Pensa ai casi d'uso come casi utente .

    
risposta data 14.11.2013 - 08:10
fonte

Leggi altre domande sui tag