Informatica Industriale

scusate ma per voi sono features o suppl requirements affermazioni del tipo "Il sistema impedisce di registrare spese se non ci sono i soldi disponibili nella relativa voce di spesa"? Sarebbe un requisito funzionale giusto? non mappa su nessuna user need ma è importante metterla..

Esiste un modello per il documento di Use Case Model Survey??

Il prof. ha detto qualcosa in merito?

Smoking_Man ha scritto:

Stavo pensando pero' che sarebbe + corretto spezzettarla in una feat per ogni campo. Qualcosa del tipo:
FEAT3 Il sistema registra, per un fondo, la seguente voce di spesa: Mat, di consumo.
FEAT4 Il sistema registra, per un fondo, la seguente voce di spesa: Mat. inventatiabile
ecc

In questo modo mappi una STRQ su ogni feature e se un domani cambia la need (ad esempio non bisogna piu' registrare la voce varie) trovi subito la feat abbinata...
Che ne pensate di questo ragionamento?

DarkSide ha scritto:

Smoking, ma facendo come hai detto non vedo più la differenza tra needs e feqtures... Cioè, possibile che c'è solo un verbo di differenza?

Nel mio gruppo abbiamo visto le needs come molto generiche; ad esempio, quando parla di tutte le caratteristiche del fondo tipo nome, eccetera come need abbiamo messo "Il sistema deve caratterizzare in modo univoco il fondo" e come features tutti i vari "campi" utili per la caratterizzazione.

Intendiamoci, manco così quadra molto, però mi sembra che abbia più "senso"...

@Smoking: non sono d'accordo sul mappare STRQ e FEAT in rapporto 1:1. A quel punto perde di senso individuare le features. L'obiettivo secondo me è (fra le altre cose) passare da (numeri a caso) 100 STRQ a 30 FEAT a 15 UC. E' vero che lui ha fatto quella divisione nelle STRQ, ma non è detto che questa debba ripercuotersi nelle FEAT.

@Darkside: mettere una feature per ogni "campo" utile per la caratterizzazione mi pare eccessivo: quelli alla fine saranno campi di una relazione nel DB, e/o attributi di una classe. Considerarli come features separate sarebbe comodo nel caso in cui queste possano poi essere mappate da casi d'uso diversi, ma in questo caso non mi viene in mente come sia possibile.

@Smoking && Darkside: una feature è "qualcosa" che fa il sistema, mentre quei "campi" descrivono molto ad alto livello parte del modello dei dati.

Tutto rigorosamente IMHO.

Smoking_Man ha scritto:

scusate ma per voi sono features o suppl requirements affermazioni del tipo "Il sistema impedisce di registrare spese se non ci sono i soldi disponibili nella relativa voce di spesa"? Sarebbe un requisito funzionale giusto? non mappa su nessuna user need ma è importante metterla..

Secondo me è più giusto metterlo nel caso d'uso appropriato. C'è quel "se" che mi chiama alla mente proprio un flusso alternativo .

Nash ha scritto:

@Smoking && Darkside: una feature è "qualcosa" che fa il sistema, mentre quei "campi" descrivono molto ad alto livello parte del modello dei dati.

Tutto rigorosamente IMHO.

perfettamente d'accordo, mi sono espresso male prima.. cioè pensavo qualcosa del tipo:

-STRQ: il sistema deve caratterizzare univocamente il fondo
-FEAT: il sistema identifica ogni fondo mediante un nome, un totale, bla bla
-Implementazione: un sistema con tutti i campi

Rimane sempre da capì che differenza c'è tra need e feature...

STRQ - User need: "1: voglio che quando clicco sul nome di un campo la tabella relativa ai 'prestiti a strozzo' si riordina rispetto a quella colonna, sia a aumentà che no... capito, no?. 2: ogni prestito ha le seguenti voci [...]. si me pare che so tutte, tanto al massimo le aggiungi dopo, che ce vole.
3: ah poi, si può fare che c'è una spranga sul bottone 'nuovo prestito'?"

Feature: "1: il sistema permette di visualizzare i record relativi ai 'prestiti a strozzo' in ordine crescente/decrescente rispetto a una qualsiasi delle colonne, nella fattispecie 'ammontare', 'interessi', 'numero fratture inflitte', cliccando sulla colonna interessata."

a) Chiaramente la 3 è un need, ma non è una feature del sistema.
b) Le feature sono un po' più formali, scritte meglio e un po' meno ad alto livello, anche se restano nel dominio del problema.
c) Le feature le scrivo io, le STRQ il cliente
d) (banale ma fondamentale) Le feature sono direttamente tracciate agli UC

Di sicuro ce ne sono altre, appena mi vengono le scrivo.