不具合が発生した際や機能を変更する際にメンテナンスしやすいよう意識して設計しましょう。

最初は必要なくても、プログラムのバージョンアップで機能追加が発生するかもしれません。

モジュールを適切に分割する等して、後から機能追加しやすいよう意識して設計するのが好ましいです。

(ただ、未来に必要になるかわからない機能を意識しすぎて設計が必要以上に複雑になると本末転倒です)

機能の一部は別のプログラムに移植されるかもしれません。

モジュールを適切に分割する等して、再利用しやすいよう意識して設計しましょう。

プログラムを構成する一部の機能を部品(モジュール)化して分割することで、保守性や拡張性・再利用性を向上できたり、

チームでの開発の場合はモジュールごとにメンバーを割り当てたり、といった効果が期待できます。

問題発生時のフェールセーフや、復旧方法を意識して設計しましょう。

パスワードなど、機密な情報を扱うケースがあるかもしれません。

暗号化を行う場合は、どういった暗号化方式が良いか、鍵はどう保持するか等も考える必要があります。

セキュリティ面を意識して設計しましょう。

タイミングや外的要因による割り込みに耐えられるように意識して設計しましょう。

処理の実行時間やメモリ使用量など、プログラムが動作する媒体の条件やユーザビリティを意識して設計しましょう。

マルチスレッドプログラミングの場合、処理が実行されるスレッドを意識して設計しましょう。

例えば、時間のかかる処理をUIスレッドで実行してしまう設計にしてしまうと、長時間UIを操作できなくなってしまう等の問題が発生します。

手続型言語での開発が主流だった頃は、設計での成果物はフローチャートや関数仕様書が主でした。

最近はオブジェクト指向言語での開発が主流となり、UMLを用いた設計が多くなっています。

それに伴い、クラス図やシーケンス図を設計における成果物としているケースが多くなっています。

関数仕様書は、Javadocやdoxygenを活用して作成するケースが増えています。

昔ながらの開発を行っているプロジェクトでは、ExcelやWordベースのフローチャートや関数仕様書を作成しているケースがあります。

設計は、細かければ細かいほど良い、というわけではありません。

設計がソースコードレベルまで細かくなっていると、ちょっとした不具合の修正だけでも設計書のメンテナンスが必要となり大変です。

ただし、言語知識やスキルが未熟なメンバーが多いチームでは、細かく詳細設計・レビューを行うことで品質の向上が見込めたりもします。

設計の粒度をシステム全体や主要機能の基本設計ないし簡易的な詳細設計までとするケースもあれば、

かなり細かい詳細設計を行うケースもあります。