Di solito ci sono dei livelli ai requisiti, specialmente se il software è complesso o quando si specifica un sistema che include sia elementi hardware che software. A seconda della complessità del sistema, puoi avere un numero qualsiasi di livelli.
Tuttavia non sono d'accordo con le tue definizioni. I requisiti riguardano sempre cosa fa il sistema (requisiti funzionali o requisiti comportamentali) o criteri utilizzati per valutare il sistema (requisiti non funzionali, requisiti non comportamentali o attributi di qualità). Hanno origini diverse e diversi livelli di granularità, ma soddisfano tutti i caratteristiche di un buon requisito .
La prima fonte di requisiti è ciò che definirei i "requisiti del cliente". Questi sono tutti requisiti che provengono dai clienti che stanno pagando per la progettazione e lo sviluppo del software o le persone che useranno il software. Questi sarebbero in genere espressi utilizzando la lingua del dominio del cliente e degli utenti. Spesso, questi dovrebbero essere tradotti in requisiti più tecnici che possono essere progettati e implementati.
Regole, leggi e regolamenti forniscono anche una fonte di requisiti. Di solito sento questi definiti "requisiti normativi" o "requisiti di conformità". Questi possono o non possono essere identificati in modo esplicito da clienti o utenti, o possono essere identificati ad un livello elevato (come ad esempio riferimento a una legge o regolamento che deve essere rispettato). I requisiti normativi specifici identificherebbero comportamenti o attributi specifici del sistema che possono essere ricondotti a un regolamento o una legge, ma non sono presenti nei requisiti del cliente.
Un'altra fonte di requisiti sarebbero i "requisiti aziendali". Questi sono requisiti che vengono richiesti dall'organizzazione in via di sviluppo. Forse c'è una strategia generale da parte dell'organizzazione di sviluppo per raggiungere una roadmap di prodotto. Per seguire questa tabella di marcia, devono essere applicati ulteriori vincoli al design del software.
Potrebbero esserci conflitti tra questi requisiti di livello superiore. Un passo del processo di ingegnerizzazione dei requisiti è analizzare i requisiti e negoziare attorno ai conflitti per ottenere una serie di requisiti che possono essere progettati e implementati. I clienti potrebbero non essere pienamente consapevoli di alcuni regolamenti di cui l'organizzazione di sviluppo è a conoscenza. Il desiderio del cliente potrebbe entrare in conflitto con una roadmap del prodotto dell'organizzazione in via di sviluppo. Questi problemi devono essere risolti dai tecnici dei requisiti.
Tutti questi requisiti di alto livello sono probabilmente scritti in un linguaggio specifico del dominio che potrebbe non essere adatto per la progettazione e il test. Tutti i prossimi livelli di requisiti sarebbero di gran lunga più tecnici. Tuttavia, quanti strati hai dipende dalla complessità del sistema.
In un sistema software più semplice, è possibile combinare requisiti utente, requisiti normativi e requisiti aziendali in un unico insieme di requisiti software. In questo esempio, avresti solo due livelli di requisiti.
In un sistema hardware / software complesso, è possibile che siano presenti più livelli, costituiti da requisiti di sistema che descrivono l'intero sistema hardware / software e quindi requisiti separati per componenti diversi. A seconda della complessità, se si dispone di più componenti, è possibile che siano presenti gruppi di requisiti su sottosistemi e componenti. Tuttavia, qualsiasi raggruppamento sarebbe per la gestione dei requisiti e dei prodotti.
Wikipedia ha anche un un po 'diverso di tipi di requisiti . Tuttavia, quella lista è un incrocio tra livello e tipo.
Suggerirei di verificare alcune risorse sulla progettazione dei requisiti per molti più dettagli. Personalmente, la mia prima scelta sarebbe Requisiti software , che ora è alla sua terza edizione. Ho sentito cose positive anche su Gestione del processo dei requisiti , tuttavia.