仕様書はどの文法時制で書くべきですか？

現在、機能および技術仕様を2列形式で作成しています。要約文と技術的詳細。詳細は、多くの場合、図、レイアウト設計などの付録を参照しています。

しかし、私はそれをどのように書くのに苦労しています：

過去の時制のように、作業が完了したかのように、既存の作業のハイライト拡張を示すのに苦労します。Xを行う必要があるため、将来の時制は、やることリストまたはTenseニュートラルのように聞こえます。

さらに混乱を加えるために、この仕様は、第一言語として英語を持っていない人々によって読まれるかもしれません。

私の最後の仕事の場所でそれをたくさん持っています。

製品マネージャーは、現在時制を使用して、次のように実行する必要があることを説明することを選択しました。

ユーザーが注文を送信します。システムは確認メッセージを送信します。

残念なことに、前提条件の記述も次のように現在形で行われました。

ユーザーはアイテムをショッピングカートに入れ、数量を指定します。

既に何があり、何がこれからであるかが明確でないため、これは私にとって多くの混乱を引き起こしました。私は彼らに未来の時制を使わせようとしたが、彼らは決して変わらない。個人的には、そこでの2年間すべてに慣れることができませんでした。それは意味をなさない、誰かが言語の時制を熟知していないように聞こえる。

したがって：

• すでに存在するものに現在形を使用する

• しなければならないことのために未来形を使用してください。世界は「すべき」、「必要」、「意志」を採用します。

現在の時制は私には良いようです。

1. 前提条件：Fooは状態Xです
2. 操作：これとそれが起こる
3. 事後条件：Fooは状態Yです

それらはすべて現在形です。

または、「プロジェクトの状態」の場合

1. バージョン10：機能A、B、C、Dがあります

2. バージョン10.1には、Aの改善が含まれています。Bのバグ1049を修正します。新機能Eを追加します。

RFCを記述するための慣習を知りたい場合があります。

これはRFC 2119です。RFCで要件レベルを示すために使用するキーワード。

仕様は指示です。それらを現在形で書いてください。このような。

ソフトウェアのデザインを作成するときは、ソフトウェアが存在する前にデザインを作成しても、現在時制を優先します。ソフトウェアアプリケーションが設計から実装された後でも、設計は関連性があり重要なドキュメントです。設計文書は、ソフトウェアが実装される前よりも、実装された後のほうが関連性が高い場合があります。