Sicuramente non vuoi che la "caratteristica unica" combinata con qualche forma contorta di YAGNI porti a ciò che spesso accade:
"Oh, so we need to allow the customer to store 3 addresses, so I'll
just add three columns to the customer table."
"Shouldn't we try to maintain a relational model with a seperate
address table and a surrogate key in case at some point a customer
needs 4 addresses."
"YAGNI, they are really gonna need to put in another feature request
for us to allow for 4 customers. You're overengineering for a use case
that doesn't exist"
"...FML"
È sempre necessaria una certa quantità di "guardare avanti". Se così non fosse, nessuno si preoccuperebbe dei modelli e delle migliori pratiche. Senza una specifica funzionale di alto livello, come dovresti dare la priorità a quale caratteristica verrà dopo. Non sono enorme su UML, a meno che non sia un abbozzo approssimativo della prima iterazione sul mio blocco note, ma la fase di progettazione deve sempre includere una sorta di descrizione funzionale di come dovrebbero comportarsi le cose. Questo potrebbe essere controindividuale, ma davvero non penso nemmeno che importi molto quello che fai con le specifiche una volta che è stato scritto (aggiornalo mentre vai, mettilo in una cartella a cui nessuno va, cancellalo, ecc. .). Il vantaggio principale del processo di progettazione e le specifiche lente sono che ti costringe a scrivere tutte le tue idee e vedere se hanno senso.