TDD.NET

TDD では、 テストケースをコードとして記述します。 そのテストコードには、 「なにをどのようにテストするのか」 と 「結果はどうなるべきか」 が、 書かれています。 テスト仕様書やテスト結果のドキュメントに書かれる内容が、 テストコードとして表現されているはずです。

テストコードの内容 ＝ テスト仕様書やテスト結果のドキュメントの内容

等価なものは 2つも要りません。 片方だけで充分です。 そういう意味では、  テスト仕様書やテスト結果のドキュメントは不要になります。
ただし、 問題があります。

・ 現在は、 技術的にユニットテストを書きにくい部分がある。
GUI の部分が代表的ですが、 そのようなところは、 ユニットテストではなく従来通りの手動テストを行うことが多いです。 手動でテストする部分については、 コードを書く前にテスト仕様書を明確に定義し、 コードを書いた後でテスト結果を検証しなければなりません。

・ コードを読めない人には、 テストの内容が理解できない。
テストコードを理解できない人にとっては、 テストコードの内容 ＝ テスト仕様書やテスト結果のドキュメントの内容、 という等式が成り立ちません。 テストの良否を判断する人がそのような人であった場合、 テスト仕様書やテスト結果のドキュメントを廃止するわけにはいかなくなります。
なお、 テストコードのメソッド名を分かりやすくし、 それを抜き出してドキュメント化したりといった工夫がされていますが、 それはあくまでも 「どのようなテストケースがあるか?」 という開発者に対しての一覧を提供するためであって、 テストケースの内容が適切にコード化されているかどうかを判断できるものではありません。
この問題については、 たとえば画面を叩いてみる単体テストを Excel のシートに記述して、 それを自動実行できるようなシカケが必要だと思います。

・ ドキュメントが必要かどうかは、 開発側だけで決められない。
これは言わずもがなですが、 お客様への納品物としてテスト仕様書やテスト結果のドキュメントを挙げている場合には、 当然ながらドキュメントも作らないといけません。

これらの問題から、 おそらくは、 画面を叩くレベル以上のテストは従来通りの手動テストとし、 それより低いレベルの ( そして大抵はロジック部分だけに絞った ) テストを TDD で実施することが、 現状では妥当な線ではないかと考えます。

さて、 ご質問への回答は以上で書けたと思うので、 苦言をひとつ。

仕様変更 → ソース修正 → 単体テスト仕様書修正 → エビデンス修正

この手順は、 よろしくありません。
手動で単体テストを行っている場合でも、

仕様変更 → 単体テスト仕様書修正 → ソース修正 → エビデンス修正

という順序で実施するべきです。
「[コラム] テストファーストは、 テストを先にやるわけではない」 に書きましたが、  テストケースというのは、 外部設計を具体的に例示したものであり、 コードを作成・修正するときのゴールになるのですから、 先に完成させておくべきものです。 あとから ( ソースを見て ) テスト仕様書を記述・修正するという順序では、 ( 開発者にとっては ) 不要になったタイミングで作るということであって、 まさに無駄な作業です。