L'autore del post sul blog stava cercando di capire come l'Agile Manifesto enfatizza il "software di lavoro su una documentazione completa" e che quando lo fai rischi di perdere le informazioni su come il software è supposto per funzionare.
Ciò che è necessario, che si tratti di Waterfall, Rational Rose, Agile o altri SDLCM, è una "dichiarazione di intenti". È una descrizione testuale di ciò che deve essere fatto, e perché, a un livello di dettaglio sufficientemente preciso nelle aree giuste, uno sviluppatore può prendere questa descrizione nella stanza del team come "requisiti" e produrre software che funzioni correttamente come un risultato dei suoi sforzi di sviluppo, guidato da qualsiasi metodologia che lui o il suo team o manager ritengano opportuno seguire.
In Waterfall, questo è il documento dei requisiti. È tutto definito, in dettaglio, in primo piano, prima che inizi lo sviluppo, e se cambia mentre il progetto è fuori per lo sviluppo, lo sviluppo si interrompe e il team ritorna alla fase di "progettazione".
In UML / Rational Rose, questa è una "descrizione del caso d'uso". Descrive ciò che l'"attore" (una persona in un ruolo aziendale specifico, o un automa esterno come un altro programma) farà ciò che dovrebbe attivare un'azione, e cosa accadrà all'interno del sistema come risultato di questa azione.
In Agile, questa è una "user story", la cui forma esatta può differire in base al sapore esatto di Agile, ma i due che ho visto sono simili a un "caso narrativo di utilizzo" di UML e un po 'diverso approccio: "Come ... voglio ... così che ...". Simile a un caso d'uso in cui sono menzionati l'attore e l'azione di base, ma l'aggiunta è un'integrazione delle esigenze aziendali nel contesto della storia, quindi quando si progetta la soluzione, il team di sviluppo può tenere a mente il business.
Nessuno di questi è un "readme", e sinceramente non vorrei leggere un readme scritto nel modo suggerito dal blogger; sarà lungo, sarà ordinato solo in base all'ordine in cui lo sviluppatore ha aggiunto le funzionalità richieste, e sarà scritto da uno sviluppatore, che avrà la sua prospettiva su ciò che sta aggiungendo o modificando e perché potrebbe non coincidere con la prospettiva che avrebbe un utente.