Dubbi sui requisiti (casi d'uso testuale e requisiti funzionali e dell'utente)

First is about the difference between the functional requirements and user requirements. The user requirements are the tasks that a type of user can perform with a system right? But that isnt also the functional requirement? For example in a site like ebay user requirements can be "Search catalog", "Pay Order", "Add item to shopping cart", Log-in", "logout", "recover password", "Get list of purchased products", right? But this arent also functional requirements? So why this distinction of user and functional requirements? Or functional requirements are not specified like this?

Nella mia esperienza, la fonte di un requisito (utenti, obblighi contrattuali, obblighi legali, requisiti aziendali) è ortogonale al tipo di requisito (funzionale o non funzionale). La traduzione di un requisito da una terminologia di un utente, di un dominio, della legge o di un'azienda a una che soddisfi i criteri di una buona esigenza è un processo.

I requisiti dell'utente sono dichiarazioni, scritte nel linguaggio naturale dell'utente, sulla funzionalità fornita da o sui vincoli sotto i quali il sistema opera. In questo caso, i requisiti dell'utente vengono trasformati in uno o più requisiti tecnici che possono essere funzionali o non funzionali.

Nel tuo esempio, l'utente può esprimere il desiderio di pagare un ordine. L'utente potrebbe non pensarci poiché non lo vedono, ma questo probabilmente porterà a una serie di requisiti che sono entrambi funzionali (come l'utente invia, archivia o aggiorna le informazioni di pagamento al sistema) e non funzionali ( trasmissione e archiviazione sicure delle informazioni di pagamento, riservatezza delle informazioni personali come numeri di carte di credito o indirizzi, gestione degli errori su più richieste duplicate e così via).

Also I read that the textual use cases are used to explore the user requirements and that then we can get the functional requirements from this analysis. So we should first identify the user requirements, like "Search catalog", "Pay Order", "Add item to shopping cart", Log-in", "Log-out", "Recover password" and these user requirements besides being user requirements are also use cases that we can create to get the functional requirements? But so, again the first doubt, which should be the functional requirements of these use cases/ user requirements above?

Considererei i tuoi esempi di "Catalogo di ricerca", "Ordine di pagamento" e altri come casi d'uso. Ho già detto che i requisiti degli utenti sono spesso specificati nella lingua naturale dell'utente (spesso la lingua del dominio). Questo viene poi trasformato in un formato che è un buon requisito (tra le altre cose, completo, non ambiguo e verificabile). Un caso d'uso è un metodo per acquisire i requisiti in modo da assicurarci che siano buoni.

Come descrivi le tue condizioni d'uso, i tuoi scenari e le post-condizioni, troverai pezzi funzionali e non funzionali. Ad esempio, in un caso di utilizzo di accesso, è possibile specificare che l'utente immetta il proprio nome utente e password e quindi li inoltra tramite un modulo protetto. I dati di input sono funzionali, mentre la sicurezza non è funzionale.

It is something like theese: "The user shall ble able to login", "The user shall be able to logout", "The user shall be able to pay an order", "the user shall be able to add an item to a shopping cart" It seems the same thing of just "Log-in, "Log-out", "Pay order".

Nessuno di questi formati è buono. Anche se "L'utente deve essere in grado di accedere" e "accedere" può essere equivalente, non sono requisiti implementabili. Non sono completi, tracciabili, ambigui, verificabili e non specificano l'importanza.

Il modo in cui scopri se è un requisito reale o meno è seguendo Robert's Golden Rule per i requisiti software:

Every genuine requirement is accompanied by an Acceptance Test that proves the requirement has been met. Does running this test clearly and ambiguously verify that the requirement has been fulfilled? If you don't have such a test, it's not a requirement; it's a "feature" or "wish."

La raccolta dei requisiti è oggetto di libri completi. Puoi avere un'idea migliore di come raccogliere requisiti legittimi e utili leggendo uno di quei libri. Vedi qui .

First is about the difference between the functional requirements and user requirements. The user requirements are the tasks that a type of user can perform with a system right? But that isnt also the functional requirement?

I requisiti utente sono un sottoinsieme di requisiti funzionali. C'è molta sovrapposizione. Ma ci sono requisiti funzionali che non sono requisiti dell'utente, ad es. "La cronologia deve essere automaticamente cancellata dopo 30 giorni."

It is something like these: "The user shall ble able to login", "The user shall be able to logout", "The user shall be able to pay an order", "the user shall be able to add an item to a shopping cart" It seems the same thing of just "Log-in, "Log-out", "Pay order".

I requisiti devono essere rigorosamente definiti con zero ambiguità. Se si è certi che "pagare un ordine" e "disconnettersi" sono termini definiti inequivocabilmente, bene. Non penso che lo siano comunque.

Invece di "un utente deve essere in grado di accedere", una serie di requisiti ben scritta può contenere quanto segue:

• Un utente finale con nome utente e password deve essere in grado di stabilire una sessione, con le seguenti eccezioni: (a) l'utente è nella lista nera (vedere la sezione XX.YY), (b) l'utente è bloccato (vedere sezione AA.BB), (c) l'utente sta tentando di accedere al sistema da un indirizzo IP in una regione di geolocalizzazione nella blacklist (vedere la sezione DD.EE.FF)
• Un utente in lista nera che tenta di autenticare deve essere presentato con il Messaggio 104.
• Un utente in stato di blocco che tenta di autenticare deve essere presentato con il messaggio 105.
• Un utente che tenta di autenticare da un indirizzo IP nella lista nera deve essere presentato con il messaggio 106.
• Un utente finale senza conoscenza di nome utente e password non deve essere in grado di stabilire una sessione.
• Un utente finale che ha stabilito una sessione deve essere in grado di navigare verso una delle pagine elencate nella Tabella 1.
• Tutti gli utenti dovrebbero essere in grado di navigare verso una delle pagine elencate nella Tabella 2, indipendentemente dal fatto che abbiano stabilito una sessione.
• Se un utente tenta di navigare verso una pagina non consentita, il sistema deve presentare uno stato HTTP 403. Nota: UX specifica potrebbe essere specifica per il browser.
• Se un browser viene lasciato incustodito, una sessione deve terminare tra 29 e 31 minuti dall'invio dell'ultima pagina.
• Al termine di una sessione, il sistema deve comportarsi esattamente come se il sistema non fosse mai stato stabilito.
• Se l'utente chiude il browser, il sistema deve comportarsi esattamente come se la sessione fosse terminata.

Ciascuna delle suddette mappe naturalmente usa casi e casi di test, dal momento che le precondizioni e le regole sono abbastanza chiare, e ogni percorso logico è spiegato separatamente. Ma ciò non significa che ci sia una mappatura 1: 1. Potresti avere molti casi d'uso associati a un requisito e quasi ogni caso d'uso deve obbedire a più requisiti contemporaneamente; i casi d'uso e i requisiti sono associati con una matrice di tracciabilità .

I casi d'uso tendono ad essere molto dettagliati e non hanno nomi semplici come "autenticarsi" o "accedere". Nella mia esperienza sono identificati da un codice di qualche tipo, ad es. "Auth-BF-01" sarebbe il flusso di base # 1 di autenticazione. Potrebbero esserci anche i flussi di base 2 e 3. I flussi di base sono anche chiamati "percorso felice".  Nel frattempo, i flussi di eccezione o di errore potrebbero essere denominati "Auth-AF-01" dove "AF" sta per "flusso alternativo". Flussi alternativi vengono utilizzati per cose come password non valida o errore di sistema.