設計仕様書を作成するとき、未来形または現在形を使用する必要がありますか？
大学のプロジェクトの設計仕様書を書いていて、使用すべき時制について疑問に思っています。プロジェクトの開発はまだ始まっていません。UIデザインセクションを書いているだけです。
使用する必要があります：
このアプリは、ヘッダー要素を含む2列のレイアウトを中心に構築されています。
または
このアプリは、ヘッダー要素を含む2列のレイアウトを中心に構築されます。
私は明らかに、ドキュメント全体を通して最善の時制を継続します。
実際に書いていることを明確にするために編集
コースモジュール記述子は次のように述べています。
要件仕様に基づく詳細な「設計仕様」。完成した設計仕様は包括的であり、サードパーティが設計仕様を実装の基礎として使用できるようにする必要があります。したがって、それは明確、簡潔、詳細でなければなりません。次のものが含まれる場合があります。さまざまなページまたは画面をリンクする方法を提案する方法を明確に示すナビゲーションマップ。ページレイアウト、配色、タイポグラフィ（フォント、サイズ、スタイル、配置）、メディア要素（アイコン、グラフィック、サウンド、ビデオ、アニメーション）の使用、またはインタラクションスタイルを説明する一連の詳細なストーリーボード。設計決定の正当化も存在する必要があります。
それはあなたが書いているものに依存します。
要件を記述している場合、答えは「どちらでもない」です。別の質問 ここでソフトウェアエンジニアリングは、要件を記述する際の「shall」と「must」の使用に対処します 。私が職場で使用しているガイダンスは、ソフトウェアが顧客に受け入れられるために満たす必要がある要件を示すために「Shall」が使用され、望ましい特性をマークする「べき」、オプションであり、「意志」は、必須および任意の望ましいまたはオプションの特性が実装された後に信頼できるものです。要件をステートメントとして記述するのではなく、 ユースケース または ユーザーストーリー を使用する場合は、その形式の規則に従う必要があります。
すでに存在するソフトウェアについて書いている場合は、現在形を使用する必要があります。ソフトウェアはすでに存在しているため、「ある」または「ある」ものです。
要件の定義と設計アプローチの文書化を同時に行う場合は、それを行わずに、ソフトウェアが公開する必要のある機能とソフトウェアの非機能属性を分離することの価値と、ソフトウェアの方法を文書化することの価値を理解することをお勧めします分解されたか、ソフトウェアの使用方法。要件、技術設計、および使用法（ユーザーズマニュアル）の分離は非常に重要です。
あなたの特定のニーズに対処するために、私がすべき最も良いことは、コースのインストラクターまたは彼らが探しているものを理解している他の誰かに尋ねることだと思います。私の経験では、このタイプのドキュメントは現代のソフトウェア開発のどの形式にも存在しません。そのため、特定の顧客（この場合、教授または学年）に受け入れられるドキュメントの作成方法を専門のソフトウェアエンジニアに尋ねることはできません。特に、「これを行わないでください。これは良い習慣ではありません。代わりに開発方法論とアプローチを検討してください」という答えは、コースのはるかに遠いところに到達するとは思いません。
要件仕様に基づく詳細な「設計仕様」。完成した設計仕様は包括的であり、サードパーティが設計仕様を実装の基礎として使用できるようにする必要があります。したがって、それは明確、簡潔、詳細でなければなりません。次のものが含まれる場合があります。さまざまなページまたは画面のリンク方法を提案する方法を明確に示すナビゲーションマップ。ページレイアウト、配色、タイポグラフィ（フォント、サイズ、スタイル、配置）、メディア要素（アイコン、グラフィック、サウンド、ビデオ、アニメーション）の使用、またはインタラクションスタイルを説明する一連の詳細なストーリーボード。設計決定の正当化も存在する必要があります。
要件仕様は、内部または外部のチームによるソフトウェアの実装の基礎です。これには、機能的な特性だけでなく、設計上の制約、パフォーマンスおよびその他の品質属性、ユーザー特性、必要なインターフェースなどが含まれている必要があります。要件の仕様は、顧客とソフトウェアサプライヤー間の合意です。
あなたがドキュメントに入れるように言われているのは、確かに設計情報です。ただし、それは ソフトウェア開発への「大きな設計の事前」アプローチ と一貫しています。ここでは、設計を「終了」するまでコードを記述しません。ただし、このアプローチを採用している組織の多くは知りません。
ソフトウェアの終了後にドキュメントを読み取るかどうかを考慮してください！
構築したいものを説明する提案を書いている場合、将来の時制は大丈夫です。
ソフトウェアの存続期間中に維持される設計ドキュメントを記述したい場合、将来の時制は意味がなく、現在の時制を使用する必要があります。結局のところ、このドキュメントでは、ソフトウェアisの設計方法について説明します。
問題ではない
重要なのはプレゼンテーションではなく、仕様の内容です。「プレゼンテーション」には言語などが含まれます。ここでの例外は、プレゼンテーションが非常に悪い読者がコンテンツの理解を著しく妨げられている場合ですが、現在と将来の時制がそのような問題を引き起こすことはありません。