la corretta descrizione del problema nell'opportuno linguaggio (formale) può molto spesso rappresentare la soluzione.
Parliamo di software: i requisiti sono una rappresentazione del problema; ma anche il design è una rappresentazione del problema. Lo è in quanto descrive (in modo dettagliato, si spera) il dominio del problema da risolvere, specificandone gli attori e le relazioni. Dove il documento dei requisiti è una descrizione passiva del problema, il design ne è una descrizione attiva.
Il software emerge da una descrizione (e quindi, da una comprensione) sempre più dettagliata del problema da risolvere.
Ahh, che bel post.
poi mi guardo attorno...
