Questi due approcci usano significati diversi della parola "comportamento".
Il primo (comportamento vs. stato) è basato su una mentalità progettuale che vede i programmi come una raccolta di stati e transizioni tra questi stati. In tale modello, "stato" è una cosa statica; se tu avessi un computer che potresti congelare o monofase (come quelli degli anni '70), allora potresti fermarlo in qualsiasi momento e controllare il suo stato (i valori attualmente memorizzati nel suo registro e nella memoria), ma osservarne il comportamento, ne hai bisogno per funzionare. È abbastanza comune visualizzare gli aspetti dinamici di un programma (parte di un) come un diagramma in cui le caselle rappresentano stati e le frecce rappresentano le transizioni tra questi stati.
Il secondo significato compensa le caratteristiche funzionali del programma (cosa fa?) contro i dettagli tecnici (come hanno fatto a fare ciò che fa?). Questa separazione è abbastanza comune; molte metodologie dividono la fase di progettazione in parti funzionali e tecniche di progettazione. In questa mentalità, il comportamento di un programma è ciò che funziona in modo funzionale e osservabile, dal punto di vista di un utente (ad esempio, quando clicco su questo pulsante qui, sopra di esso appare un mucchio di testo fittizio); l'implementazione, al contrario, è come viene eseguita (ad esempio, c'è questo modulo HTML con un pulsante di invio, e lo script sul lato server legge la richiesta POST lanciata da quello script, chiama un servizio web per generare un lorem ipsum e lo inserisce nel modulo che poi viene rispedito nella risposta).
Il primo significato è interessante, perché decidere cosa vuoi modellare come stato (dati) e cosa vuoi seguire implicitamente attraverso il comportamento ha un enorme impatto su qualsiasi progetto software. Rendere i tuoi dati troppo rigidi ti rende inflessibile ai cambiamenti futuri; mettere troppe informazioni nella tua logica e troppo poco nei tuoi dati rende un pasticcio intrattabile di logica complessa.
Il secondo è importante, perché consente di specificare i requisiti senza prendere decisioni tecniche (ancora). Se i requisiti funzionali sono chiari e chiari, è possibile verificare che il progetto tecnico soddisfi i requisiti funzionali e, successivamente, durante i test di accettazione, è anche possibile verificare che il prodotto reale soddisfi i requisiti funzionali (che è molto più importante del soddisfacimento del requisiti tecnici: a chi importa se non hai usato XML, a patto che la cosa faccia ciò che dovrebbe fare).