「ソースが全てだ。」という人がいます。プログラムのコメントの意味ならは、納得できますし、賛同します。
読みやすいコメントを書くのと、読みやすいソースを書くのとの比較論は彼方此方で交わされてます。
意味不明なコメントより一目瞭然のソースのほうが理解が早いです。
ところが、これを拡大解釈して、システム(プログラム)処理書にも適用しているケースが過去いくつかありました。
システム処理書と実装を対にして置くのは至難な事は知ってます。一人もしくは、数人程度で作成する小さいシステムならば、処理仕様をソースを追いかけても対処可能な事も知ってます。
でも、主要テーブル(常時更新)が10個以上でサブシステムが複数個存在するシステムで、処理書と実装が不一致なのは頂けません。
更新項目対応表や業務テータフローなど、要件仕様が実装と不一致なのは、後々不味いことになります。
中規模以上のプロジェクトになると仕様書などの書類で机上で設計することが多いので、機能と実装が食い違う事態になれば、設計書を訂正しなければいけません。
「時間がない」と後回しにすると、反映されずになってしまう可能性が高いです。
小規模システムと開発者と運用者が同一でも、何時本人が活動不能になるか分かりません。実装と機能書の保守は同程度に重要な事だと思うのです。