Si potrebbe disporre, come riferimento, di specifiche di requisiti provenienti da sistemi precedenti o correlati in
altro modo: possono essere utili per la stipulazione di un percorso. Oppure si potrebbe aver iniziato ad usare Rational
Unified Process un po' di tempo dopo l'inizio del progetto.
Con il gruppo, riesaminare ogni requisito per individuare i comportamenti dell'applicazione o gli attributi di
comportamento. In generale, durante questo percorso di riesame, ignorare le informazioni esplicative come le
introduzioni e le descrizioni generali relative al sistema.
Stipulare un elenco di tutte le problematiche individuate ed accertarsi che qualcuno venga incaricato di risolverle.
Potrebbe essere necessario effettuare delle supposizioni, se un requisito non è chiaro. Tenere traccia delle
supposizioni in modo da poterle verificare con gli stakeholder.
Ricordarsi chi ha scritto i requisiti. Cercare eventuali "requisiti non validi", cioè cose che sono al di fuori
dell'ambito del progetto. Quando non si è sicuri se si tratta di un requisito o meno, contattare gli stakeholder.
L'esecuzione di questi tipi di percorsi è molto efficace se si utilizzano delle strutture esistenti di casi d'uso come
framework. Ogni requisito deve ricollegarsi ad almeno un caso d'uso nella struttura. Se non è disponibile un caso d'uso
a cui relazionarsi, è un'indicazione che manca un caso d'uso o che il requisito non è valido.
|