ITプロジェクトの要件の品質について、率直に言って（開発チームの立場から）。 パート2

パート1は、 リンクをクリックして見つけることができます

仕様要件の設計ガイドラインと例

彼らが話さないこと、誰もが自分のやり方で理解する

前のセクションで発表したように、ソフトウェア開発の要件を、チームの作業を簡素化およびスピードアップして最終製品に変えるような形式で変換しようとします。

仕様に慣れるための読者の準備

では、提示された要件について開発チームの知り合いはどこから始めることができますか？ 将来のパフォーマーへの彼の創造のアナリストによるプレゼンテーションで間違いなく。 両者にとって、最初のコンタクトがどの程度うまく確立され、新しいプロセスに入るための障壁が克服されるかは非常に重要です。 しかし、多くの場合、多くの理由で、これを行うことは不可能であるか、直接問題になります。 そのため、ドキュメントの冒頭に、その構造の簡単な概要と情報の表示、およびそれを正しく効果的に使用する方法の説明を含むセクションを含めることをお勧めします。



ドキュメントレビューの例：







開発したシステムのコンテキストをよりよく理解するために、ドキュメント構造で必須として選択したセクションに加えて、ターゲット製品またはその複合モジュールの開発の結果として達成されるべき目標に関する情報を含めるようにします。 開発者は、プロジェクトの終了時に顧客が受け取りたいものを認識する必要があります。 このセクションの説明には、正式な顧客ニーズが適しています。 同様のセクションは、ほとんどの標準、たとえばGOST-34.602-89 [4]にあり、「システムの作成（開発）の目的と目的」と呼ばれています。



次のようになります。







後続のドキュメントアーティファクトを開発する場合、上記のセクションで記録したユーザーニーズへのリンクを添付する必要があります（各ニーズには独自の識別子があるため）。 したがって、プロジェクトの対象製品が満たさなければならないすべての目標が、その実装中に満たされることを確認できます。

ターゲット製品のコンポーネント構造を視覚化する

大規模プロジェクトの主な問題は、多数のコンポーネントを使用する必要があることです。 この事実は、製品の全体像のチームメンバーの想像における共通のアイデアを著しく妨げる可能性があります。 この悪と戦うために、対象製品の一般的なコンポーネントアーキテクチャを説明するセクションをドキュメントの冒頭に追加しようとしています。 このセクションは、ターゲット製品のすべての主要なノード要素を1つ（または複数）の画像に表示し、それらの間の相互作用の方法とモードの説明を理解するのに役立ちます。



Aivar Jacobsonは「Unified Software Development Process」[5]で、アーキテクチャという用語に次の定義を与えました。「これは重要な特性と陰影の詳細を強調したプロジェクト全体の表現です」。

このセクションの中心的な要素の代わりに、私の意見では、アーキテクチャ図の表記法が理想的です。 このタイプのプレゼンテーションは、コンポーネントの標準的な図に似ていますが、専門家の幅広いサークルが理解するために、より視覚的でアクセスしやすいように見えます。



以下は、システムアーキテクチャの説明を含むセクションの要件に含まれる部分です。







読者が理解しやすいように、このような大ざっぱな図面にテキストを添付することをお勧めします。







この表現は、複数のチームがプロジェクトに関与している場合に特に役立ちます。 彼らは、システムのコンポーネント間の接触のポイント（インターフェース）とそれらの（チーム）の相互作用を明確に判断できます。 一般モデルを理解することにより、初期段階で隣接する作業領域の実行者の責任の「たるみ」を回避できます。



文書がシステム全体ではなく、その部分のみを考慮している場合、この部分はダイアグラム上で色付きで強調表示できます。 したがって、異なるドキュメントでは、コンポーネントアーキテクチャの同じ図を繰り返すことができますが、異なる部分（コンポーネント）は色で強調表示されます。

ダイナミクスの対象製品を想像してください

顧客の一般的なニーズを聴衆に紹介し、開発された製品のアーキテクチャを視覚化したとき、読者はすでにその主要な機能とシステム全体の構造についての考えを持っています。 これで、その使用の主なシナリオを詳しく知ることができます。 GOST-34.602-89 [4]では、そのようなセクションは「システムによって実行される機能（タスク）の要件」と呼ばれます。



多くの場合、このようなセクションを配置するとき、ダイアグラムは要件で使用されます：UseCaseまたはビジネスプロセスの説明（BPMN）、実行アルゴリズム（アクティビティ）、またはIDEF0機能モデルなど。 これらのタイプのダイアグラムはすべて、プロジェクトの範囲を定義するなど、設計段階で不可欠です。 しかし、私の経験から、それらはプログラマーにはほとんど役に立ちません。 このドキュメントの対象となる開発者の観点からは、構造化されたテキスト記述の形式で提示された、設計されたシステムを使用するシナリオを具体的に扱う方がはるかに快適です。 この段落の上記のすべてを要約すると、私は注意します：誰も使用しない情報でこのセクションをオーバーロードしないでください。しかし、目的のセクションに到達するために毎回スクロールします。



以下は、私が実際によく使用するシナリオ記述オプションです。 このアプローチを開発する主な基準は次のとおりです。

• 説明で作業する参加者は特別なトレーニングを受けておらず、表記を自由に読むことができません。
• 説明の読者は、ターゲット製品（モジュール、サブシステムなど）を使用してユーザーが実行するすべてのアクションを明確かつ完全に想像する必要があります。
• プロセスを記述するためのベストプラクティスの手法を使用して、情報を構造化して提示する必要があります。

こうしたシナリオは、開発者が将来、静的オブジェクトとシステムコンポーネントを実装するプロセスで、相互作用のダイナミクスをすばやく明確にするのに役立ちます。 したがって、さらに、エンティティ、フォーム、手順などの説明で それらが関与するスクリプトへの参照を使用する必要があります（他のすべての仕様オブジェクトと同様に、スクリプトの利点として識別子があります）。



同じシナリオは、要件の別の消費者グループであるQAスペシャリストの作業の基礎として使用できます。これは、テストシナリオに非常に近いためです。

構成要件と仕様の形式を決定する

要件の仕様-これは答えがあるソリューションではなく、一貫したアクションプランです

すべての習熟セクションが準備できたので、ドキュメントの重要な部分である機能要件の仕様の作成に進むことができます。これは、開発者のタスクを作成するための出発点として役立ちます。



仕様はグループ化し、情報のブロックとして適切に構造化する必要があります。 最低レベルのブロックは、タスクの形で開発者に転送する準備ができているアトミックな要件でなければなりません。 したがって、各仕様には、開発者が明確化および明確化のために作成者に連絡することなく、要件を明確かつ完全に実装できるようにするのに十分な情報を含める必要があります。 このようなアプローチにより、プロジェクトマネージャーは、実際の負担をかけずに仕様を検討し、詳細なプロジェクトスケジュールを作成するための「空白」のセットを作成できます。 それについては後で詳しく説明します。

リポジトリから始めましょう

仕様に従う構造と順序を決定するプロセスで合意したように、要件の開発者による実装の段階は、データウェアハウスの形成から開始する必要があります。 したがって、仕様の私のバージョンでは、このトピックに専念する最初のセクションです。 セクションの冒頭で、ドメインモデルのより完全な理解のために、一般的なデータ構造を提供することが望ましい。 これはクラス図を使用して行うことができ、非常に人気があり、ほとんどのIT専門家に知られています。 このイメージにより、開発者は構造全体を一度に熟考できます。 次に、モジュールで使用される個々のエンティティの仕様を詳述する必要があります。



以下は、問題のプロジェクトの仕様の例です。











したがって、このような要件を受け取った開発者は、データベースオブジェクト（以下DBと呼びます）を生成するためのコードにしか変換できません。 このような操作を実行するには、資格の低い専門家を引き付け、プロジェクトの予算を節約できます。



モジュール（システム）をサブシステムに分割することをお勧めします。これにより、各リーダーは3〜7の実装されたエンティティの数で動作します。これにより：別のサブシステム）。



同様のセクションはGOST-34.602-89 [4]にあり、「情報ベースの組織の説明」と呼ばれます。

データストレージから、視覚的なフォームでの表示に移りましょう

このモジュール（サブシステム）で実装する必要があるすべてのエンティティを説明した後、視覚的なフォームの開発を開始できます。 フォーム要件は、同じスタイルで便利にフォーマットされます。 説明するときは、開発が進行中のプラットフォームが提供するユーザーインターフェイスの視覚的なコンポーネントに依存することが重要です。 フォームを記述するときは、前のセクションで説明したデータベース要素が属性を視覚的に表すために使用されることを示す必要があります（識別子も持っているため）。 また、開発者が開発しているものと画面上のすべての動きをより完全に想像できるように、フォームの説明で、リンクを指定することを忘れずに、このフォームが使用されるシナリオに言及する必要があります。











複雑な属性（[UI1.2.2.a9]など）の場合、表には、関連付けられているエンティティへのリンク、データ選択の制限、フォームに表示するフィールド、フォーム上のリンクをたどる規則などがすぐに記載されていることに注意してください。 d。 各属性について、システムの視覚コンポーネントに対応するビューが示されます。 このような詳細で明確な説明により、開発者は予測可能な品質でタイムリーにユーザーインターフェイスの要件を簡単に実装できます。 詳細なディテールにより、資格の低い人材を仕事に引き寄せることができ、プロジェクトマネージャーがタスクをチームに効率的に分散して、プロジェクト全体の収益性を高めることができます。

ビジュアルフォームの動作を与える

ビジュアルフォームが指定されたら、その動作のプログラムを開始できます。 したがって、次のセクションでは、通常、フォームイベントを処理するときに自動的に実行できる、またはGUI要素（ボタン、メニューなど）を操作するときにユーザーが開始できるすべての手順を紹介します。



使いやすくするために、各要件仕様には一意の識別子を割り当てる必要があります。 これらの識別子は、要件自体と図を含む他のプロジェクト成果物の両方で、リンクとして使用できます。 アクションの記述の変形、特に識別子生成アルゴリズムは、以下の要件の例で見ることができます。







モジュールがボリュメトリックアルゴリズムの説明、入力および出力パラメーターの定義、追加のデータストレージ構造の開発などを含む複雑な機能を使用する場合、ドキュメントに補助機能の要件を含む別のセクションを含めます。 上記のフォームのアクションを説明する仕様によって参照される場合があります。 たとえば、ヘルパー関数は、フォームの異なるイベントで同じ基本関数が呼び出される場合に便利です。 同様のセクションはGOST-34.602-89 [4]にあり、「アルゴリズムの説明」と呼ばれます。



以下は、同様の表現の例です。







さらに、ドキュメントセクションでは、オプションでレポート、定期タスク、高度な検索などが続きます。 上記の例に示すように、これらの項目に同じレベルの詳細を入力し、使用されているエンティティ、手順などへのリンクを示すことをお勧めします。

セキュリティの世話をします

このようなシステムのドキュメントで言及する必要がある別の重要なセクションは、アクセス権に専念しています。 その中でロールが識別され、それらの説明が与えられ、データオブジェクトとユーザーインターフェイス要素へのこれらのロールのアクセス権が示されます。



以下は、アクセス権管理サブシステムの要件の例です。







上記の役割テーブルの例では、利害関係者の目標などの説明がないことに注意してください。 これらの詳細は、要件を作成する段階のアナリストにとって重要ですが、開発者にとっては実質的に役に立ちません。 次のステップでは、わかりやすくするために、列としてリストされたロールに許可されたアクションが利用可能なものに固定されるセルにテーブルを作成できます：プロシージャ、データベーステーブル、ユーザーインターフェイス要素など、行として示されます。 また、許可されたアクションは、たとえば、英語の単語の最初の文字の形式（C-Create、R-Read、W-Writeなど）で示すことができます。











同様のサブセクションは、たとえばGOST-34.602-89 [4]にあり、「不正アクセスから情報を保護するための要件」と呼ばれています。



最後のパートでは、 リンクの専門家によるこのような要件仕様、PMおよびQAの効果的な使用の例を示します。

。