Nella terminologia a cui sono abituato, i tuoi usi per le parole non sono allineati. Tuttavia, potrebbero esserci definizioni alternative in uso da parte di altre organizzazioni.
Nella mia esperienza, ci sono più fonti che pongono i requisiti su un prodotto software. Il cliente e gli utenti hanno dei requisiti, che è quello che chiamerei "requisiti del cliente". Queste sono le caratteristiche del sistema che il cliente e gli utenti ritengono necessario. Tuttavia, i requisiti possono anche provenire dal business (la società che produce il software), in genere a causa dell'esperienza di dominio e della conoscenza del continuo sviluppo del prodotto tra i clienti. I requisiti possono anche provenire da fonti normative: governi, leggi, standard di settore.
I requisiti del cliente possono richiedere una cura di qualche tipo. È probabile che il cliente non soddisfi requisiti totalmente utilizzabili dal punto di vista tecnico. Ci possono essere incoerenze, ambiguità o incompletezza che devono essere risolti. Tuttavia, anche dopo il grooming e il buy-in, sono ancora requisiti dei clienti.
Il team di ingegneri prende i requisiti da queste fonti per sviluppare i requisiti del sistema (e sottosistema / componente) che riguardano il particolare prodotto. Questi requisiti sono un perfezionamento del cliente, degli affari e dei requisiti normativi. Al livello più alto del sistema, hanno ancora bisogno di discussione e negoziazione con il cliente poiché i requisiti aziendali e normativi potrebbero essere in conflitto con i requisiti del cliente e questi conflitti devono essere risolti.
I requisiti funzionali sono semplicemente un tipo di requisito. Un requisito può essere tipicamente chiamato "requisito funzionale" o "requisito non funzionale". Anche i requisiti non funzionali sono talvolta definiti "attributi di qualità". Qualsiasi requisito (cliente, azienda o normativa) potrebbe essere funzionale o non funzionale.
Ci sono altre cose che possono essere incluse nelle specifiche dei requisiti. Questi sono chiamati vincoli di progettazione - cose che non descrivono la funzionalità o le caratteristiche del software ma influenzano il tuo design. Ad esempio, se il cliente esegue solo ambienti Windows, il fatto che il software verrà distribuito su Windows è un vincolo di progettazione. I vincoli di progettazione possono anche derivare da requisiti aziendali o normativi, ma in genere i requisiti dei clienti o aziendali sono alla base dei vincoli di progettazione.
Nel tuo specifico esempio, direi che l'utente è in grado di inserire dati in un formato specifico è un requisito dell'utente. Al fine di mantenere una linea di prodotti o esigenze di sicurezza, potrebbero esserci requisiti aziendali o normativi sulla convalida dei dati, sull'integrità dei dati, sui checksum o sull'hashing. I tuoi requisiti di sistema sarebbero informazioni sufficienti a qualcuno per progettare e testare un sistema. Chiamerei l'uso dei vincoli di progettazione Java e Oracle DB.