AからZまでのITプロジェクトで要件を作成する方法。パート1.入門

プロローグ

このサイトでプロジェクト管理に関する記事を読むと、プロジェクト内のリソースの非効率的な使用が原因で、マネージャーの苦痛がしばしば感じられます。 そして、これらの問題の主な原因の1つは、ほとんどの場合、製品開発の品質タスクの欠如と正確に呼ばれています。 この不幸は、さまざまな症状で現れる可能性があります：抽象的で曖昧なタスクの委任の難しさの形で、または全員が頭の中でしか持っていないソリューションについての会議での相互誤解は、まったく異なる方法で提示されるなど 彼の心の中でこれについて読むことは、彼自身の練習からの写真を鮮明にフラッシュしました。 そして今、あなたはすでにストレスを感じており、この頭痛を取り除くための症状からレシピに素早く切り替えようとしています。 そして、私たちは最も頻繁に何を見ることができますか？ そして、原則として、楽観的で決定的なものがスローガンになります-エグゼキューターのタスクを正しく準備します、彼らがすぐにそれを理解する、すべてを推測する、または彼らが突然洞察を得ることを期待しないでください。 待って！ どうやってやるの？ 何らかの理由で問題を提起した著者は、その解決策の検索は読者が独立して作業できるように残されています。 しかし、これは最も面白くて難しいものです。



私の記事「ITプロジェクトの要件の品質について（率直に言って（開発チームの立場から）」）で 、これらの問題に具体的にアプローチしようとし、ITプロジェクトで収集された要件を自動化して最大化する方法を教えてくれましたそれらをターゲット製品に変換するチームのパフォーマンス。 プロセス全体をカバーする製品の開発のための定性的に定式化されたタスクにより正確に増加すること。



ここで、要件を定性的に定式化して、顧客を「ウィッシュリスト」からソフトウェア製品との幸せで実り多い共同生活、夢へと導く方法をお伝えしたいと思います。

はじめに

...要件を定式化する方法のどれがあなたに最も適しているかを理解するには、常識に導かれ、あなた自身の経験に頼るべきです。

カール・ウィガース

この出版物の対象者および目的：



キャリアの夜明けに、私はプログラマーとして働き、開発チームを率いて、コーディング、コーディング、コーディングを行いました。 しかし、18年後、システム分析とプロジェクト管理の分野に突入して、活動の種類を変更することにしました。 幸運なことに私が働いていた企業は、アナリティクス、プロジェクトマネージャー、プロダクトマネージャー、そして当時私にとって異国的な他の専門分野を提供していなかったため、プログラマー自身が何らかの形でこれらの専門分野のプロジェクト活動を管理する必要がありました。 当然、これらの同じ活動は非常に専門的には行われず、すべてに時間または基本的な知識が欠けていました。 これらのギャップを埋めるために、機能要件、RUP、SADT方法論、UMLなどの開発に関するコースを勉強するために、私は真剣に座っていました。 しばらくして、私は幸運にも、有力なソフトウェア会社の1つに「リードカスタマリレーションスペシャリスト」という哀れな肩書きを持つ職に就くことができました。 雇用主は、私がプロのアナリストとしての経験はないことを知っているが、願望、開発者の理論的知識と豊富な実務経験のみを知っており、2か月間で高品質を書く準備ができている[1]、[3]ソフトウェア開発の仕様要件。 プログラマーとしての私の経験から、私にとって最も親密なものはクラス図でした。 そして当然、これは私が最初に理解しようとしたことです。 同時に、Coburn [3]に従ってユースケースを記述しようとしましたが、彼が自分の考えを表現することは非常に「甘い」ので、そのようなものを調理してみたいと思います。 オプションは面倒で難解であることが判明しました。最初はこれらのオプションの形式を理解する必要があり、そのときだけコンテンツについて理解する必要がありました。 彼らと仕事をするのは不便でした。 私の意見では、より成功したのは、RUPで観察されたパターンに従って作成された要件の仕様です。



適応の結果として、要件管理の分野からいくつかの基本的な方法論と技術を研究した結果、どこから始めるべきか、どの手順を踏むか、各設計段階でコンテンツの最適量はどうあるべきかを漠然と想像しています。 私の仕事の成果を運命づけられた人々は、異なるプロジェクト成果物のセットのみを受け取り、その使用は効果的に適用できませんでした。 理論的にはすべてが透明で明確でしたが、私の特定のプロジェクトでは、すべてが何らかの形で間違っていました。 システム分析の理論は、芸術として私に知覚されました。優雅で調和のとれた図、新しい創造的なアイデア、および実践は、特定のプロジェクトの最終結果を必要としました。

道徳：最良の材料でさえ、材料のセットと、それらから料理を準備するためのレシピブックは、あなたが常に高品質の製品を生産することを可能にしません。 知識に加えて、実践的なスキル、経験、創造的なアプローチ、および結果として得られる直感が必要です。

プロジェクトに参加する実際の経験は、アナリストにとって非常に重要です。 得られた知識を、品質要件の開発に必要なスキルに変換できるようにするのは彼だけです。 時間が経つにつれて、スペシャリストは顧客のニーズを特定するための特定の「俊敏性」、顧客がしばしば自分自身でさえ定式化できないエンティティや現象を迅速かつ正確に定義する能力を獲得します。 また、器用さは、主なオブジェクトと対象領域の参加者の環境を決定する際に開発されます。何らかの方法で影響を及ぼしますが、経験の浅い外観のために影に残ります。



要件管理トレーニングのもう1つの重要な側面は、個人管理の分野のアナリストのトレーニングです。 スペシャリストの個人的な有効性のトピックは、要件の処理に専念する作品には事実上開示されていません。 そして、この種のスキルの欠如は、専門家としてのアナリストの成功した自己実現を非常に複雑にします。 異なるチームのプロジェクト機能は常に厳密に規制されているわけではありませんが、多くの場合、プロジェクトの役割間でぼやけています。 したがって、プロジェクトの関連分野におけるアナリストのスキルが広いほど、実際に成功する可能性が高くなります。



これらすべての考えから、システムアナリストとしての仕事の始めに読みたい本を書くために座った。



この本の主な目標は次のとおりです。

• ソフトウェア製品設計プロセスの「技術ライン」の可能なオプションの例を示します。
• 要件開発の各段階の手法と方法論を定義および構成します。 意思決定のさまざまな分野でこれらの手法を使用するためのオプションを選択します。
• アナリストが利害関係者と通信し、プロジェクトでの彼の仕事の結果を効果的に促進できるようにする管理手法を説明します。
• ソフトウェア要件の開発プロセスで重点を置くべき重要なポイントを特定します。

さあ行こう...

IIはじめに

要件管理に関する大量の文献が現在入手可能です。 ほとんどの作品は、4つのグループに分けることができます。

1. RUPやSADTなど、特定の基本的な「重い」方法論を説明する理論情報を提供します。 これらの方法論は、大規模プロジェクトに非常に効果的で便利です。 しかし、それらを使用するには、既に成功裏に適用されている企業でのトレーニングや練習など、長い学習プロセスが必要です。 このグループのアナリスト向けの古典的な研究は、[1]、[2]と考えることができます。
2. 要件管理の分野のプロセスに関する学術的観点の声明。 個人的に、本[4]、[5]は私を大いに助けてくれました。
3. 比較レビューの形でのさまざまな技術への遠足。 私の意見では、本[6]は、このグループのアナリストにとって最も成功した作品ですが、学術的な作品のグループに帰することができます。 さまざまなプロジェクトで使用する方法の選択について、記事[9]に簡潔かつわかりやすく説明されています。
4. 「簡単な」方法論の形で提示される実用的なアイデア。ほとんどの場合、小規模プロジェクトを対象としています。ICONIX、エクストリームプログラミング（eXtreme Programming）[7]、[10]などのプロセス。 このような方法論は、小規模なチームで効果的に使用するために比較的迅速に開始できます。

この出版物は、学術研究やデザイン方法論を主張するものではありません。 ほとんどの場合、機能要件を開発および管理するプロセスのいくつかのオプションを教えるセミナーとして位置付けられます。 私の仕事では、実際にテストされたさまざまなテクニックと方法論を紹介します。



この出版物は物語の形式で提示されます。 要件開発プロセスの原則と基礎の定義と説明は提供しませんが、関連トピックが完全に開示されている出版物への参照を使用しています。 提示された資料を理解するには、読者がシステム分析の分野を理解している必要があります。



出版物のすべてのセクションには、実世界で発生する特定のイベント、プロセス、エンティティ（または、私たちにとって最も重要な側面）の画像をシミュレートした写真が装備されています。 材料をセクションからセクションへと公開するとき、モデルは補足され詳細になり、設計プロセスのダイナミクスを示します。



また、プレゼンテーション全体を通して、お客様と一緒に、「要件管理プロセスの自動化」という非常に現実的なプロジェクトを検討します。

IIIチームのランドスケープを準備する

「あらゆる風景は、特定の思考構造を表現するための理想的な身体です。」

ノバリス

複雑な製品の要件とプロジェクト文書の開発は、非常に骨の折れる作業であり、適切に調整されたチームワークを必要とするほか、長いプロセスです。 したがって、最初から、このプロセスが発生する風景（生息地）を考えて準備する必要があります。 私の意見では、プロジェクトアーティファクトを操作するための快適な環境を提供することと、プロジェクトアーティファクト間の通信を行うことは、その（プロジェクト）が正常に完了するための重要な側面の1つです。



このグループの作業の目的：ターゲット製品の要件の開発と実装の一環として、プロジェクトチームの高品質で効果的な対話の条件を準備する。



エンタープライズオートメーションプロジェクトは、多くの場合、組織自体の複数の変更に関連付けられています。 チェンジマネジメントの分野の専門家は、まずチェンジマネジメントが人々の関係と感情状態の管理であるため、仕事を始める前に従業員の「動機付け」と「準備」の段階を経ることをお勧めします。 したがって、プロジェクトを成功させるには、開発チームだけでなく、顧客側を代表する参加者にも意欲が必要です。 これは品質要件の開発とプロジェクト全体の両方にとって最も重要な成功要因の1つであるため、シムを無視しないでください。



顧客と仕事をする際に、従業員に絶えず感情的な動機を与える必要性に特別な注意を払う価値があります。これは、プロジェクトで起こるすべてに関心を示すよう促します。 いっそのこと、彼らはプロジェクトのために有用性の点で互いに競わせてください。 これには、プレゼンテーション、ディスカッション、トレーニングなど、多くの方法とテクニックがあります。



ほとんどすべてのITプロジェクトは、自動化されるビジネスプロセス、環境などに関する情報の収集から始まります。 このプロセスの目的は、すべての利害関係者がプロジェクトの最終結果の共通の解釈に同意することです。 プロジェクトの参加者は、情報を扱う分野で異なるレベルのトレーニングを受けているため、資料はさまざまなグループが理解できるように、さまざまな（ただし事前定義された）形式で提示する必要があります。 言い換えると、さまざまな程度の詳細、抽象化のレベル、表記法の使用、その他の特性があります。 したがって、プロジェクトのコンテンツをすぐに少なくとも2つのドメインに分割します。

1. 「問題の領域」と呼ばれる、将来の製品の消費者の観点からの初期ビジョンの情報。 問題が存在する現実世界の知識に基づいて
2. 実装に関する情報-「ソリューションエリア」と呼ばれる開発者からのビュー。 ソリューションを実装できるテクノロジードメインの知識に基づいています。

要件は、さまざまな割合ではありますが、プロジェクト全体で収集されるため、このすべての時間が実装の過程と最終結果に影響します。 最終製品が顧客のニーズを最大限に満たすように、そして私たちが知っているように、実装中に変更できるように、プロジェクト全体を通して最終製品の消費者との密接で生産的な対話を維持する必要があります。 それが重要であるので、私たちは材料のプレゼンテーションの過程で絶えずこの論文に戻ります。 上記に基づいて、「問題ドメイン」と「ソリューションドメイン」の両方のプロジェクトドメインが同期的に変化し、相互に依存することが非常に重要です。



したがって、プロジェクトの最初から、すべての参加者がアクセスできる情報を備えた「討論プラットフォーム」を用意しておくとよいでしょう。 サイトはプロジェクトの「ショーケース」として機能する必要があり、仮想（例：WEBポータル）または現実（例：スタンドのある部屋）のいずれかで、コンテンツ、プロジェクトの現在のステータス、および即時計画に関する重要な情報を配置できます。



各観点の代表者の絶え間ない相互コミュニケーションは、当事者による誤った仮定の問題に効果的に対処するのに役立ちます。

• 顧客が説明する問題は、彼が実際に解決する必要がある問題ではない場合があります。
• 開発者が説明するソリューションは、実際に作成するものとは異なる場合があります。

図3.1は、プロジェクトコンテンツの形成と使用のプロセスにおけるプロジェクトチーム間の相互作用のモデルを示しています（「問題領域」と「ソリューション領域」）。





図3.1-プロジェクトチームの相互作用のプロセスのモデル



プロジェクトのランドスケープを準備する段階で、利害関係者のリストを作成し始めます。 プロセスと（または）新製品の作成結果に何らかの形で関わっている人を見逃さないことが重要です。 プロジェクトの利害関係者は、システムおよびプロジェクトチームの将来のユーザーだけでなく、さまざまな顧客担当者、投資家、人間工学の専門家、標準化および規制機関の担当者などにもなります。 このリストは、要件が形成および指定されているため、プロジェクト全体で更新および更新できます。



リストの設計は、関心のある人の名前に加えて、目標を明確にし、プロジェクトでの能力と役割を分類する必要がある表の形で便利です。

以下は、テーブルを使用してプロジェクト関係者のリストを作成する例です。







プロジェクトのランドスケープを形成するためのもう1つの合理的なステップは、「ウィンドウ」-辞書（用語集）での公開です。これは、対象領域のオブジェクトおよび現象の解釈で合意に達するためのツールとしてチームに役立ちます。 これにより、顧客と開発者は紛争について「同じ言語」でコミュニケーションできます。 経験から、用語集を使用すると、顧客と請負業者が同じ用語の理解の違いによってのみ生じる「独自の」紛争に費やすことが多いため、時間を節約でき、最も重要なのは神経を節約できることがわかっています。 たとえば、タイトルで使用されている「Landscape」という単語は、アプリケーションに応じて非常に異なる解釈が可能です。 しかし、プロジェクトのコンテキストでは、用語集に次の定義を追加します。







用語集はプロジェクトのライフサイクル全体を通じて更新できるため、出版物でプロジェクトを開発する際に、異なる解釈を引き起こす可能性のある用語を定義します。



この章からわかるように、プロジェクトのすべての利害関係者とアナリストの積極的な相互作用、またはむしろ、要件の開発への絶え間ない感情的な関与に特に重点を置いています。

中国民俗の知恵：「教えてください-そして私は忘れます。 見せてください-そして私は覚えています。 私を魅了し、学びます。」

アナリストは「芸術のためではなく」ソフトウェア開発チェーンで使用される中間製品として要件を作成することを常に思い出してください。できるだけ多くの利害関係者を結成してください。この製品の所有権をチームに伝えます。答えを知っていても、質問してください。



人々がこの決定を自分自身のように感じる一方で、彼らがあなたに必要な答えをあなたに与えることができるように質問をしてください。図3.1からわかるように、要件



の一方の側には、ターゲット製品の実装のためのチームがもう一方の側にあります。したがって、利害関係者の関与について話すときは、顧客だけでなく、アーキテクト、プロジェクトマネージャー、Timlidsも意味します。なぜなら、あなたの仕事は最終的に彼らのために設計されているからです。



彼らと相談し、彼らから学び、彼らのために「彼ら自身」になってください。これらは単なるアピールではありませんが、実際にどのようにこれを行うことができるかについての私の見解を共有します。



次のパートでは、プロジェクトの目的を策定し、参加者と利害関係者と利害関係者を特定し、顧客リンクの一般的なニーズを特定します。



トピックに関する著者のトレーニングについて：「ITプロジェクトでの要件の形成の実践」は、 IC Tavrida LLC会社のWebサイトで見つけることができます。