機能要件-動詞に基づく表現を使用しますか？

質問

要件ドキュメントの機能要件では、動詞に基づく表現を使用する必要がありますか？

環境

学校の割り当て、チームでの作業、SDLCによる作業。要件ドキュメントが作成され、設計に取り掛かりました。

問題

要件のドキュメントには、アプリの機能と呼ばれるもの、つまり機能要件の一覧が列挙されています。その中には、「何を」ではなく「どう」だと思いますが、今、デザインに取り組もうとすると、デザインの一部が時期尚早に規定されているような気がします。

私はこれを前にやったことがありません！私にとっては、「何を」ということを厳密に扱うべきです。

現在の例

仕事がオムレツを作ることであるふりをします。リスト：卵を割る、ボウルに割り込む、スクランブルなど; どのように領土に線を越えます。そのトラックに沿って、次のような表現も作成します。作成、生成、リスト、計算、決定、検証など-基本的に動詞。現在、部分的に動詞に根ざしている要件のリストがあります。

オムレツの要件ドキュメントについての私の考えは、2つの卵、xオンスのハム、xオンスのベーコン、xオンスのモンテリージャックチーズ、xオンスのコリアンダーなどなどです。何も（名詞） 。

経験があれば、要件ドキュメントを完成させる前に、発言した可能性があります。

要件では動詞を使用できます。重要なことは、各要件が次のとおりであることを確認することです。

• 明確 -各要件は1つのことだけを意味し、1つの方法でしか解釈できません。
• アトミック -各要件を複数の要件に分割することはできません。
• テスト可能 -各要件は、何らかの形のテストを介して満たされているかどうかを示すことができます。

これらの3つのガイドラインをすべてのコストで守るだけで、要件がどれほど優れているかがわかるでしょう。

また、各要件の根拠を必ず記述してください。これは、特定の要件が作成された理由を誰かが疑問に思うときに、非常に重要で便利です。

そして、はい、あなたは正しいです。要件は、ソフトウェアがどのように実行するかではなく、ソフトウェアが実行することを説明する必要があります。

「要件ドキュメントの機能要件では、動詞に基づく表現を使用する必要がありますか？」

短い答えは「はい」ですが、そこへの道は曲がりくねっています。

要件ドキュメントが英語の文章として書かれた「shall」ステートメントのコレクションである場合は、動詞句が必要です。そして、その動詞句は「システムはxxx」のように「shall xxx」になります。「xxx」の部分は、「be」、「do」、「have」の3種類の動詞の1つです。これらの文は、システムをブラックボックスとして説明し、外部から見えるもののみを記録する必要があります。あなたが言ったように、「どのようにではなく、何を」。外から見えると「なに」。

デジタルシステムで使用できる唯一の可能な関数は、変数の値を変更することです。したがって、すべての機能要件には、変更される変数と、変更を行うために使用される計算が記述されている必要があります。これらは「実行」要件です。

「be」要件は、機能ではなく機能を記述する傾向があります。「システムは...できるはずです。」彼らは「存在の状態」を説明しています。

「持っている」要件は、あなたが話していた名詞です。「システムは...を持たなければならない」それらは、機能要件文の名詞を提供します。

高レベルでは、機能要件はほとんどありません。要件のほとんどは、機能要件、パフォーマンス要件、または構成（所有）要件のいずれかです。

子供を必要とするすべての高レベルの要件は、定義上、あいまいです。彼らが明確であるならば、彼らはそれらを定義するために子供を必要としません。さらに、要件レビューの大多数の人々がそうであると宣言した場合に限り、要件は明確です。つまり、あいまいさは主観的です。私が知っている明確な機能要件の最も近い定義は、「明確な機能要件」ページのBarBaraBea.comにあります。基本的には、機能要件のすべての名詞は明確な機能要件のチェーンを通じてシステム入力から派生する必要があり、要件の計算のステートメントはアルゴリズムを記述する必要があると述べています。「アルゴリズム」の定義は、「明確な要件」の定義よりも主観的ではありません。

...オムレツを作ることが仕事のふりをします。リスト：卵を割る、ボウルに割り込む、スクランブルなど; 方法の領域に線を越えます...
...
オムレツの要件文書の私の考えは、次のようなものになります。2つの卵、xオンスのハム、xオンスのベーコン、xオンスのモンテジャックチーズ、xオンスのコリアンダーなど-何だけ（名詞）...

オムレツについては、私は最初のバージョンの要件を2番目のものよりも優先します。これは、2番目のバージョンが卵2個、ハムxオンスなどを得るリスクがあるためです。

2番目のバージョンでは、必要なものを確実に入手できますが、多少面倒です。要件が満たされていることを確認する唯一の方法は、キッチンで食事を作るすべてのステップを注意深く監視することだからです。

ご存知のように、食事の準備方法を見ることを余儀なくされることなく、結果をテスト/検証できるようにするための要件が​​望ましいと思います。

これを実現する1つの方法は、参照に対する比較を渡すように要件を指定することです。オムレツの例を使用して、私はあなたと同じ指示に従って私自身の「参照」オムレツを作り、それからそれに十分に近いかどうかあなたのものを比較します。

• ^{特定のアルゴリズムの大幅に最適化されたバージョンをテストする必要があるときに、このアプローチを使用しました。この場合の「参照オムレツ」は、最適化されていない単純化されたアルゴリズムによって提示されました。2種類のアルゴリズムで同じ入力を実行し、最適化されたバージョンによって生成された出力が参照に十分近いかどうかを確認しました。}

別の方法は、これらが結果を説明するように要件を述べることです。「4オンスの卵、スクランブルとフライなど」のようなオムレツの場合。私は主にこの種の要件を扱いました-これは最も典型的な方法だと思います。

• ^{完全を期すために、私が扱った要件のもう1つの種類を指定する必要があります-テストベース。「専門家がそれを見て味わうとき、彼らは大丈夫だと言う」のようなものなど、オムレツの例で不自然に聞こえない方法を想像することはできませんが、認めなければなりません。 、それは特に賢くも感じませんでした。}

関数型プログラムは関数で構成されています。関数とは何ですか？アクションを実行するメソッドです。アクションワードとは 動詞。

オブジェクト指向プログラミングを行っている場合は、名詞を扱うことになります。実際には、名詞と動詞の両方を使用します。

機能的なスタイル：

crack(egg)

オブジェクト指向のスタイル：

egg.Crack();

要件レベルでは、これが問題になるかどうかはわかりませんが、関数はあなたが書くものなので、要件がアクションの形で記述されていると確かに役立ちます。

すべての要件は、本質的に動詞の使用を中心に展開するステートメントのコレクションに減らすことができます。はい、いくつかの名詞と形容詞を投入することができますが、システムがどのように動作するかを説明するのは動詞であり、顧客がソフトウェアに何をしてほしいのかということです。プログラムの状態固有の機能の多くでさえ、ゲッターメソッドとセッターメソッドを通じて状態を提示するときの動作の観点から考えることができます。

CFL_Jeffが彼の回答で言及しているのと同じように、システムの動作を説明する要件を持ち、それがどのように行われるべきかを説明する必要はありません。動詞の使用は要件を記述し、単体テストを記述するときの動詞の使用は要件をテスト対象の動作として記述するため、動機付けの開発は非常に説得力があると私が思う理由です。

少しの間、以下の要件とシナリオテンプレートを検討してください。

• As an {actor} I want to {do something} in order to {achieve an outcome}
• Given {an initial context} When {something is done} Then {expect an outcome}

BDDでは、機能は常にテンプレートの「欲しい」セクションで説明されているビットであり、機能には何が行われるかを説明する動詞が常に読み込まれます。テスト時には、Given-When-Thenテンプレートを使用して、機能に関連する特定のシナリオを検証します。テンプレートの「When」セクションは、常に、使用される動詞によって常に定義されます。これは、何らかの方法で機能仕様で使用される動詞に関連付けられます。

オムレツの例を使用すると、いくつかの動作をシリーズとして定義することは非常に理にかなっています。行動と結果のコレクションがあり、シリーズとしてワークフローを形成します。代わりに成分のリストを定義する場合は、アーキテクチャを非常に大まかに説明していますが、多くの疑問が残ります。ワークフローとは？具材はどう使うの？基本的に、システムを組み立てる方法やシステムの動作に関する決定を導く「接着剤」が欠けています。

動作と結果の観点から要件を定義することにより、ソフトウェアでそのような結果を具体的に達成する方法について心配することなく、ソフトウェアが達成したいことを非常に明確に示すことができます。