システム要件の検証と検証

しばしば混乱するのは、検証と検証の2つの概念です。 さらに、システム要件の検証は、システム自体の検証と混同されることがよくあります。 これを整理することをお勧めします。



「オブジェクト全体および構成としてのオブジェクトのモデリング」の記事で、オブジェクト全体のモデリングと構造体の2つのアプローチを検討しました。 現在の記事では、この部門が必要になります。



設計された機能オブジェクトを用意しましょう。 このオブジェクトは、別の機能的なオブジェクトの構築の一部として、私たちによって考慮されます。 オブジェクトの説明が含まれるように、オブジェクトの構造の説明があります。 そのような記述では、オブジェクトは全体の記述を持ちます。つまり、オブジェクト構築のフレームワーク内の他のオブジェクトとの相互作用のインターフェースが記述されます。 オブジェクトを構造体として記述します。 構造としてオブジェクトの記述の設計の要件を含む情報オブジェクトがあるとします。 推論の規則を含む知識体系があり、それに基づいて、オブジェクト全体の構造からオブジェクトの構造が得られます。 知識の本体は、研究所のデザイナーが教えるものであり、多くの知識です。 オブジェクトに関する知識に基づいて、その構造を設計できます。



だから、あなたは始めることができます。 オブジェクトが全体として正しく記述されている場合、知識の本体が正しい場合、および推論の規則が守られている場合、オブジェクトの構造の結果の記述は正しいと言えます。 つまり、この説明に基づいて、実際の動作条件に対応する機能オブジェクトが構築されます。 発生する可能性のあるリスク：



1.オブジェクトに関する誤った知識の使用。 人々の頭の中のオブジェクトのモデルは、現実と一致しない場合があります。 たとえば、彼らは地震の本当の危険を知りませんでした。 したがって、オブジェクトの要件が誤って定式化される場合があります。



2.オブジェクトに関する知識の不完全な記録-何かが欠けていて、間違いがあります。 たとえば、彼らは風について知っていましたが、言及するのを忘れていました。 これにより、オブジェクトの要件の記述が不十分になる可能性があります。



3.無効な知識体系。 他のパラメーターよりも質量の優先順位を教えられましたが、速度を上げる必要があることがわかりました。



4.オブジェクトの説明に対する推論規則の誤った適用。 論理エラー、オブジェクトの設計要件に何かが欠けている、要件のトレースに違反しています。



5.システムの設計に関する調査結果の不完全な記録。 誰もが考慮し、誰もが計算したが、書くのを忘れていた。



6.作成されたシステムが説明と一致しません。



すべてのプロジェクト成果物は、原則として、プロジェクトの最後にのみ完成した形式で表示され、それでも常にではないことは明らかです。 しかし、開発がウォーターフォールであると想定する場合、リスクは私が説明したものと同じです。 各リスクの確認は、名前を付けることができる特定の操作です。 誰かが興味を持っているなら、あなたはこれらの用語を思いつき、表明しようとすることができます。



検証とは何ですか？ ロシア語では、検証はルールへの準拠のチェックです。 ルールはドキュメントの形式で作成されます。 つまり、ドキュメントの要件を備えたドキュメントが必要です。 ドキュメントがこのドキュメントの要件を満たしている場合、検証に合格しています。



検証とは何ですか？ ロシア語では、検証は結論の検証です。 つまり、オブジェクトに関するデータに基づいて構造の説明を取得する方法を説明する知識が必要です。 これらの結論の正しい適用の検証は検証です。 検証には、記述の一貫性、完全性、および理解可能性の確認が含まれます。



要件の検証は、これらの要件に基づいて構築された製品の検証と混同されることがよくあります。 これはやる価値がありません。