ITプロジェクトの要件をAからZに形成する実践。パート2.目標とニーズ

IV目標の決定、プロジェクト

目標を達成する必要はありません。 時にはただ進むべき方向にすぎないこともあります。

ブルース・リー

異種のコンポーネントと区別するシステムの主な機能の1つは、システムの組織全体を特定の目標に従属させることです。 チームのプロジェクト作業も特定のシステムであるため、何らかの目的で「リードをたどる」必要があります。 したがって、プロジェクト参加者間のコミュニケーションを確立したら、新しい製品を作成した結果として達成したい目標を決定し始めます。



この作業グループの目的：プロジェクトに参加している利害関係者のグループによって自分自身に設定されている主なタスクを決定する。



現在、文献では、目標を決定および定式化するための多くの方法が利用可能です。 そのような方向さえあります-目標設定、目標設定のルールを教える。



私の意見では、このセクションの冒頭の引用は、ソフトウェア開発プロジェクトにおける目標の役割を完全に示しています。 私の練習から、プロジェクト開始段階で策定された目標に戻ることは非常にまれです。 この文脈で目標を策定することは、スローガンを宣言し、チームの精神を高め、チームに彼らの近い将来について一緒に話し合うための開始を与える宣言的なステップです。 目標設定の専門家による声明の批判的な評価を防ぐために、すぐに目標を詳述する要件を策定することを予約します。 これらの要件は、SMARTテクノロジーのすべての原則を満たします。 SMART-5つの基準（特異性、測定可能性、達成可能性、結果の方向、限られた時間）に従って目標設定の有効性を評価するための方法論。



プロジェクトマネージャーの観点から、正しく定式化された目標により、次のことが可能になります。

1. プロジェクトの実装中にチームが作成する必要がある製品、およびその完了の結果として顧客が受け取るべきメリットを特定します。
2. 顧客だけでなくプロジェクトチームも含め、主要な利害関係者の観点から、プロジェクト全体の成功の基準を決定します。

したがって、この段階でのアナリストの目標は、チームと顧客にこの情報を提供することです。



目標を決定する際には、2つの重要な点を考慮することが重要です。

1. 顧客はほとんどの場合、目標を質の高い方法で独自に策定することはできません。
2. 顧客、請負業者、請負業者のさまざまな代表者に対するプロジェクトの目的は異なり、時には矛盾します。

したがって、まず、顧客の代表者がターゲット製品の実装の結果として達成したい目標を策定するのを支援する必要があります。 第二に、顧客の目標を策定するとき、作業の結果として達成したい独自の戦略的開発目標を考慮する必要があります。 たとえば、開発されたシステムの機能を組み込む試みである場合があります。これは、顧客にとって必須ではありませんが、開発されたターゲット製品を市場に投入するために興味深い特性です。



繰り返しになりますが、プロジェクトの目標を策定する際には、プロジェクトでの活動の結果として達成したい独自の（実装チーム）戦略的利益をそれらに組み込むことを試みる必要があるという事実に特に注目します。



ただし、顧客の目標を決定するとき、アナリストはまず、検討中のターゲットシステムの各機能を使用することで所有者が受ける利益の概念を操作する必要があります。 したがって、顧客が何らかの機会を実現するようにあなたに求めるとき、すぐに考えて、彼がこれからどんな利益を得るかを彼に教える。 そのため、初期段階でも、過剰な要件の一部を却下し、プロジェクトの境界を決定する段階で時間を節約できますが、それについては後で詳しく説明します。



図4.1は、情報システム作成の目標を形成するプロセスを示しています。







図4.1-目標を形成するプロセスのモデル



要件開発プロセスの一般的な目標を破棄したので、設計中のトレーニングシステム「要件管理」が既存の顧客のニーズを満たすために解決しなければならない主なタスクを選び出します。 トレーニングプロジェクトでは、アナリストの機能も実行し、顧客の活動を模倣するため、各目標の策定について「共同」の考えを示します。



まず第一に、自動化されたサブジェクト領域の問題と解決策を説明する利用可能なソースに目を向けるべきです。 SWEBOK（Software Engineering Body of Knowledge）によると、要件プロセスの要件分析は、次の主要コンポーネントで構成されています。

• 要件の引き出し、
• 要件分析
• 要件仕様
• 要件の検証。

したがって、このワークフロー全体を採用する必要があります。 そして、前の章で見たように、すべてのプロセスとプロジェクト参加者に単一の「環境」を使用して、単一のスタイルを遵守して、それらを実行することが望ましい。



したがって、要件を開発するときに実行する最初のプロセスは、顧客のタスク、目標、および問題に関する情報の収集であり、作成された（ターゲット）製品の助けを借りて解決します。 これらの要望に基づいて、実装のさらなる作業に適した特定の顧客ニーズ（ユーザー要件）が策定されます。



用語集に用語を追加します。







この情報を修正し、追加および変更の可能性があるプロジェクトのすべての関係者との議論のために必ず提供する必要があります。 私たちのシステムの最初の目標はどこから来たのですか？



1.ターゲット製品のヘルプで満足したいユーザーニーズのリストを修正します。



お客様との自動化の必要性（問題領域）に基づいて、以下で説明する周知の技術を使用して、開発中の製品（ソリューション領域）の仕様を策定します。 ソフトウェア開発プロセスのほとんどは要件仕様に基づいて構築されているため、システムの次の目標は次のとおりです。



2.開発製品の機能およびシステム要件のリストを修正します。 小さな説明を追加します。ユーザーの要望（問題領域）の範囲をシステム要件（ソリューション領域）で修正することを含みます。



用語集の用語要件に同意します。







要件仕様は、システム内で、顧客のニーズ（仕様に明確に関連しているため）からプロジェクトのすべての部分をターゲット製品に実装された機能にリンクするフレームワークになります。 これを行うには、仕様に基づいて、設計、開発、テスト、展開、パイロット実装などのタスクを実行者に行います。 コード内の開発者は、タスクへのリンクを示します。 タスクについては、要件などを調べることができます。 ユーザーのニーズとは逆の方向に。 上記の仮定に基づいて、次の目標を策定します。



3.要件の仕様に基づいて、最終製品での実装を目的とした実行者にタスクを割り当てます。



タスクが完了したという事実は、実際には、計画された特性への製品の機能のプロモーションを実行するため、タスクの実行者が実行したすべてのアクションをシステムで修正する必要があります。 したがって、対象製品の機能の増分を時間と個々の要件に関して追跡できます。 したがって、次の目標は次のように定式化できます。



4.実行者によるタスクの遂行の事実を修正する。



ほとんどすべてのプロジェクトでは、実装中に要件の変更と明確化が行われます。 これは「要件の分析」の分野の別のセクションであり、プロジェクトでこのプロセスに言及することはできないため、もう1つの目標があります。



5.要件の変更を管理します。



主な目標がわかったので、次に、目標を満たす顧客ニーズの策定に移ります。

V顧客のニーズの改善

ソフトウェア開発プロセスを改善するすべての可能な方法のうち、最大の利点は要件を策定することです。

カール・ウィガース

複雑性に対処するための「システム分析」の分野では、抽象化や分解などの基本的な手法を使用して、プレゼンテーションレベルの要件をレイアウトできます。 これらの原則に従って、分析ピラミッドの目標は、たとえば前のセクションで説明されています。 立ち上がり、それらをより小さな要素に分解し、開発された製品の機能に対する顧客の希望を収集します。



この一連の作業の目的：顧客のニーズに関する最も完全で正確な情報を収集し、ターゲット製品の助けを借りて満足させたい。



顧客のニーズを収集する場合、覚えておく必要があります：システムの潜在的なユーザーが、目標のいずれにも関連付けられないことを希望する場合は、このニーズを自動化する必要性を顧客に明確にするか、目標を再度修正する必要があります。



もう1つの重要な注意点：ソフトウェア製品に関してユーザーのニーズを説明しようとしないでください。これは悪い習慣です。 「メニューでの選択」、「ボタンを押す」、「フィールドへの入力」などの表現は避けますが、たとえば「オプションの選択」、「プロセスの実行」、「値の決定」などを使用します。 。







図5.1-顧客のニーズを形式化するプロセスのモデル



さらに、このモデル（図5.1を参照）を拡張および詳細化し、要件仕様を作成するプロセスのセクションからセクションに移動します。

1.顧客のニーズを判断するためのユーザーストーリーの実行

私の意見では、プロジェクトの最初から、「ユーザーストーリー」を記述する方法を使用することは非常に便利です。 このテクニックは、スクラムアジャイルプログラミングテクニック、かんばん[10]で詳しく説明されています。 その本質は、チームがプロセスの所有者とともに、自動化されるビジネスプロセスのシナリオを1つまたは2つの文で小さくするという事実にあります。 ユーザーストーリー（英語のユーザーストーリー）ごとに、実装の結果として達成する必要がある目標が決定されます。 目標を定式化するのが難しい場合は、プロセス全体でこのシナリオを使用することの適切性について考える必要があります。



ユーザーストーリーの形成は、開発中の製品の将来の消費者がその作成プロセスに直接関与することを意味し、共著者（または失敗した場合はパートナー）になることを理解することが重要です。 そして、この事実は、作成された製品の品質に対する責任を共有する必要性を顧客の意識に伝えることによって、使用されなければなりません。



ボードに貼り付けられたステッカーにユーザーストーリーを書くと便利です。ステッカーはプロジェクトチーム全体が常にアクセスできます。 この場所は通常、会議に使用されます。これは、発表されたビジネスシナリオの自動化プロセスの段階に関する共同議論です。 ステッカーにカスタムストーリーを作成することで、ステッカーが大きくなりすぎないようにします。



ユーザーストーリーがライフサイクル（フォーメーション、ディスカッション、実装、テストなど）を通過すると、開発段階に対応するさまざまな「パス」に説明付きのステッカーが接着されます。 したがって、小規模プロジェクトでは、説明した手法を使用して、最上位プロジェクトのコンテンツだけでなく、その実装プロセスも管理します。 プロフェッショナルな要件管理ツールを使用する大規模プロジェクトでこのアプローチを使用することをお勧めします。 この方法は実用的であるだけでなく、心理的な重要性も大きく、プロジェクトのチーム精神に影響を与えます。 ユーザーストーリーの例を図5.1に示します。







図 5.1。 ユーザーストーリー



ユーザーストーリーは受け入れテストにも効果的に使用できます。



上記の目標に基づいて、ユーザーストーリー（機能要件）の収集と公開を開始します。



そのため、次のビジネスプロセスをサポートするソフトウェア製品を開発する必要があります。



US01。 ステッカーにユーザーストーリーを説明します。 プロセスの目的を明確にします。

目的：ビジネスプロセスを修正して、ディスカッションにアクセスできる形式で自動化する。



「US01」-この例では、プロジェクトアーティファクトのタイプを示すプレフィックス（ユーザーストーリー）とそのシリアル番号で構成されるユーザーストーリーの識別子です。 用語集に用語を追加します。







概して、開発中の製品に対するユーザーの希望の表現スタイルとコンテンツは、控えめに言っても理想的ではありません。 チームの他のメンバーにこれらの希望を示したとしても、問題の本質を理解していないことに直面しています。 したがって、各ユーザーストーリーを関心のある参加者と話し合い、それを明確かつ単音節で定式化することをお勧めします。 次のように書きます。



US02。 プロジェクトの参加者とユーザーの履歴について話し合う。 必要に応じて変更します。

目的：プロジェクトチームをビジネスプロセスシナリオに慣れさせる。 それを揃えます。



ユーザーストーリーをさらに使用するには、システムで修正する必要があります。 たとえば、ユーザーストーリーを対応する要件にリンクすることにより、チェーンを通じて最終製品での実装を追跡できます：ユーザーストーリー→作成された要件→要求に応じて設定されたタスクなど 私たちは定式化する：



US03。 一貫したユーザーストーリーをシステムに公開します。

目的：システムで、会計および処理に関する承認済みビジネス要件のリストを修正します。



ユーザーストーリーは作成者または作成者のグループによって作成され、彼らの関心の範囲内にある問題の見解を提示するため、システムでこれらの「利害関係者」を修正する必要があります。 プロジェクトの開発では、ターゲット製品の入手に何らかの形で関心を持っている人々の輪を特定することが非常に重要です。 このデータに基づいて、要件の調整、ユーザーロールの定義などを行います。



US04。 ユーザーストーリーに基づいて、プロジェクトの主要な利害関係者を特定します。

目的：プロジェクトの参加者と利害関係者のリストをシステムで修正します。



ユーザーストーリーは、プログラムコードの作成をすぐに開始する理由を与えません。これは、実際にはプロセスの明確な見方であるためです-宣言またはドラフトです。 まず、プロセスの実装を明確に規制する、明確化された、詳細な、開発されたアルゴリズム、サブジェクト領域のオブジェクトの構造のモデリングなどが必要になります。 したがって、メインのユーザーストーリーの修正プロセスが完了したら、それらを実装するプロセスとオブジェクトのモデリングに進みます。 途中で、接続と情報の流れを決定します。 このように定式化しましょう：



US05。 ユーザーストーリーに基づいて、開発中のシステムの基本的な機能要件を決定します。

目的：システム内で自動化するビジネスプロセスのリストを修正します。



開発された製品の完全な機能を決定した後、利用可能なリソースを使用して、このリスト全体を予定どおりに実装することは現実的ではないことがよくわかります。 次に、機能を次のように分割する必要があります。必要なプロセスと機能をサポートするために不可欠ですが、今のところはそれらなしで実行できます。 これらの考えを1つの文に絞り込んで、修正します。



US06。 自動プロセスの準備リストに基づいて、優先度と優先度を決定します。

目的：プロジェクトの現在の境界を決定します。



開発された要件のすべてのプロセス、クラス、ストレージ、およびその他のオブジェクトを設計する場合、これらすべての情報を単一のコアに「紐付け」して、表記法、文書記述、その他のアーティファクトの要素を接続する必要があります。 このようなコアは通常、要件の仕様です。 これらは、構造化データの形式で記録され、一意の識別子を持ち、上記のすべてのアーティファクトが参照します。 次のユーザー履歴を記録します。



US07。 自動化のために特定されたプロセスに基づいて、製品への実装の要件仕様を策定します。 システムに要件を登録し、ユーザーストーリーと関連付けます。

目的：システムに登録する：コンテンツ、プロジェクトコンテンツの概念的コンテンツ、製品開発の基礎を提供する自動化サービスの本質の表現、テスト、運用への移行。



仕様を作成すると、低レベルのシステム要件の完全なリストとその実装の詳細な説明が得られます。 このリストに基づいて、設計、開発、テスト、展開、パイロット実装などのために、実行者にタスクまたはタスクチェーンを送信できます。 タスクがオンデマンドで設定されると、システム内のタスクの状態は自動的に変更されます。 したがって、仕様のリストでは、どの要件がすでに機能しているのか、どの要件がまだ並んでいるのかがわかります。 また、仕様はユーザーストーリーに関連付けられているため、チェーンを通じてそのステータスを追跡できます。



US08。 要件の仕様に基づいて、実行者のタスクを策定します。 タスクの実行中に、要件のステータスを変更します。

目的：要件に基づいて、ターゲット製品でのプロジェクト実装プロセスを保証します。



請負業者に設定されたタスクは、システムで利用可能になります。 タスクはオンデマンドで設定されるため、請負業者はその仕様とそれに関連するすべての要件の仕様を熟知できます。



作業が完了すると、請負業者は進捗レポートを修正し、タスクを「閉じます」。 オンデマンドでタスクチェーンを閉じると、その状態の変更が自動的に開始されます。



US09。 請負業者がタスクを完了したという事実を記録します。 リクエストのステータスを変更します。

目的：請負業者がタスクを完了したという事実に基づいて、プロジェクト実施プロセスの更新を確実にします。



多くの場合、対象製品の最初のプロトタイプの開発後、その作業に慣れているユーザーは「洞察」にアクセスします。 彼らは、「これ」または「これ」ではないことを望んでいないことを明確に理解し始めます。 要件を修正する必要があります。 見かけの単純さにもかかわらず、これは非常に骨の折れるプロセスであり、プロジェクトのすべてのアーティファクトを通じて変更を行う必要があります。 場合によっては、最初から変更（ユーザー履歴の修正）を行ってから、要件の形成のすべての段階を変更する必要があります。



US10。 製品に実装するための仕様要件を変更します。 リクエストのステータスを変更します。 必要に応じて、ユーザー履歴と同期します。

目的：製品開発、テスト、および運用への移行の基礎を提供するコンテンツのコンテンツを変更すること。



要件管理プロセスは、達成度の継続的な監視に関連付けられているため、現在の状態を含むプロパティのさまざまなセクションの要件の配列を選択できる便利なツールが必要です。



US11。 さまざまなセクションの現在のステータスとともに、要件の完全なリストまたは限定的なリストを提供します。

目的：プロジェクトの対象製品の開発プロセスの現在の状態に関するデータを取得します。



プロジェクトのプロモーションの過程で、次のことができます。新しいユーザーストーリーを追加します。 承認されたストーリーをレイアウトし、その実装に直接関与するグループで詳細に説明します。

2.顧客との話し合いのために、要件の視覚化を使用します

分野「システム分析」のもう1つの効果的な手法は、モデリングです。 本[13]のエリック・エバンスは、「開発チームのすべてのメンバーが話す言語であり、翻訳者なしで対象分野の専門家とコミュニケーションを取ることもできる」とモデルを位置付けています。 したがって、顧客やプロジェクトチームのメンバーとやり取りするための一連のモデルを選択するほど、協力はより緊密かつ生産的になり、それに応じて、お客様のニーズをより完全かつ効率的に満たすことができます。



わかりやすくするために、関連する一連の機能（ビジネスコミュニケーションの図のシナリオ）を表すモデルの形式でユーザーストーリーを表示できます。 正準図とは異なり、ここでは、さまざまなタイプのオブジェクトを比較的自由な形式で表示できるため、明確性が増します。



これは主要な設計要素の1つであるため、モデルの定義を示します。







ユーザーストーリー形成モデルの例を図5.2に示します。







図 5.2。 ユーザーストーリー生成シナリオ



この図では、プロセス、プロセスの順序と実行場所、およびリソースが明確に示されています。



このような図面を使用すると、顧客は主題領域を表現し、開発中の製品の要件について話し合うことが容易になります。 しかし、このタイプの図表を利害関係者に渡す際には、口頭の、またはより書面による説明を添付する必要があります。 たとえば、上の図のプレゼンテーションには、次のテキストを使用できます。



図の中央部分には、ビジネスシナリオ「ユーザー履歴の形成」が描かれています。 スクリプトは、実行する順序でマップされた4つのプロセスで構成されます。 下の部分はプロセスのエグゼキューターを示し、破線はその影響を示し、碑文は役割を定義します。 ダイアグラムの上部には、プロセスの場所が表示され、線はプロセスを通過するデータフローを示します。

3.顧客のニーズを判断するプロセスの準備

, , , , . , «» , , .



— , . , «» , .



, , , . .