Tradizionalmente i requisiti sono visti come istruzioni di testo che rientrano in una delle categorie menzionate nel Concetto: Requisiti. Ogni requisito asserisce "una condizione o una capacità alla
quale il sistema si deve conformare".
Per eseguire una gestione
requisiti efficace, si è appreso che è utile estendere ciò che si gestisce come requisiti oltre i "requisiti
software dettagliati". Si introduce la nozione di tipi di requisiti per facilitare la separazione dei
diversi livelli di astrazione e gli scopi dei requisiti.
Si potrebbe voler tenere traccia delle "esigenze" ambigue, oltre alle richieste formali, provenienti dagli stakeholder per esser certi di seguire come vengono affrontate. Il
documento relativo alla Visione è utile per tenere traccia delle "esigenze chiave
dell'utente" e delle "funzioni" del sistema. Il Modello di caso d'uso è un metodo efficace per esprimere i "requisiti
software" funzionali in modo dettagliato, quindi potrebbe essere necessario tenere traccia dei casi d'uso e gestirli come dei requisiti, come anche le istruzioni
individuali contenute nelle proprietà del caso d'uso che asseriscono le "condizioni o le capacità alle quali i sistema
deve conformarsi". Le Specifiche supplementari possono contenere altri "requisiti
software", come i vincoli di progettazione o i requisiti legali o di regolamentazione sul sistema. Per una definizione
completa dei requisiti software, i casi
d'uso e le specifiche supplementari possono essere impacchettati insieme per
definire un'SRS (Software Requirements Specification) relativa ad una particolare
"funzione" o altri raggruppamenti di sottosistemi.
Più un sistema è vasto e sviluppato in modo intricato, maggiore è il numero di le espressioni o dei tipi di requisiti
e maggiore è il volume dei requisiti. Le "regole di business" e il manifesto della "visione" di un progetto riconducono
alle "esigenze dell'utente", alle "funzioni" o agli altri "requisiti del prodotto". I casi d'uso o altre forme di modellazione e altre specifiche supplementari dirigono i requisiti della progettazione,
che possono essere ulteriormente scomposti in "requisiti software" funzionali e non funzionali, rappresentati nei
modelli e nei diagrammi di analisi e progettazione.
Ulteriori informazioni sull'argomento sono contenute in:
Concetto: Requisiti
Concetto: Gestione dei requisiti
Concetto: Tracciabilità
White paper: Applicazione della gestione requisiti ai casi d'uso
|