パート2は、 リンクをクリックして見つけることができます
プロジェクト管理での要件仕様の使用
導入部では、プロジェクト参加者のグループが言及されました。これについては、生活を楽にし、要件を効果的に使用するための条件を提供することも約束しました。 記事で提案されたアプローチを選択するとき、これらの尊敬される人々は何を得ますか？
このような詳細な仕様の作業を計画する場合、初期段階であっても、実装に必要なリソースと用語を高精度で決定することができます。 テーブル、フォーム、関数、レポートなどの作成にかかる時間 1つのプロジェクトの例で計算でき、将来このデータを参照として使用できます。 そして、私たちの仕様には、すべてのテーブル、フォーム、手順などがリストされています。 その数を数えるのは難しくありません。
しかし、もちろん、エラーと手順があります-手順は異なるため、より正確な計算のために、実装されたオブジェクトの複雑度係数を使用できます。 たとえば、「複雑な形式」-1.5。 「通常のフォーム」-1; 「単純なフォーム」-0.5。 要素のタイプごとに、独自の係数値の行を選択します。 この方法で得られたデータをスプレッドシートに入力し、サブシステムおよびプロジェクト全体の人\日または人\時間（必要に応じて）の総コストを引き下げることができます。
簡略化した形式では、労働強度の予備計算の表は、たとえば次のようになります。
これは、プロジェクトのコーディングコストの予備計算、およびテスト、指示の開発、および顧客への転送準備の他のプロセスに非常に便利なツールです。 このようなテーブルは、仕様を作成する段階でも構築を開始できます。この場合、それらが完成して洗練されると、必要なリソースの変化を観察し、優先作業の選択または一般的な実装の実行可能性を決定できます。
それだけだと思いますか？ そして、このためだけに、このような詳細な仕様の準備にだまされました。 しかし、いや、これは最初のステップにすぎません。 仕様のヘッダーが表示されているコンテンツの例を見てください。
これは、構造化されたタスクリストのように見えませんか？
下位レベルの各仕様を開発者のアトミックタスクに可能な限り類似させようとしたため、PMスペシャリストは仕様の要件からのみ選択し、プロジェクトスケジュールを作成するツールに転送することができます。 さらに、仕様項目は、実装すべき順序で続きます（これは私たちが処理しました）。 さらに、上位レベルのセクションはプロジェクトスケジュールにタスクのグループとして配置され、下位レベルはタスクとして直接配置されます。 仕様ヘッダーがタスクのタイトルに対して長すぎる場合、それらは変換できますが、仕様識別子は強化されたままです。これはプロジェクトの軸です。
以下は、仕様のスケジュールを作成する例です。
それでは、技術的な問題：リスク計画、リソース割り当てなど。
当然、このアプローチは要件管理に取って代わるものではありません。 それらは変化し、優先順位が変わり、さらに多くのことが起こる可能性があるため、要件のトレーサビリティを使用することをお勧めします：ユーザーのまさにニーズから、高レベルの要件、そして仕様およびプロジェクトスケジュールの計画まで。 そのため、すべてのステップで、オブジェクトの識別と、要件内の関連するアーティファクトへのリンクのチェーンを構築しました。
製品品質管理での要件仕様の使用
上記のように、このような仕様は、QAスペシャリストにとってはまさに楽園です。なぜなら、これらの仕様には、対象製品に対するユーザーアクションを記述する非常に詳細な形式のスクリプトが含まれているからです。 テストケース、受け入れカードなどの基礎を形成できるのは彼らです。 ビジュアルフォーム、レポート、ユーザーインターフェイス要素へのユーザーアクセス権、手順、およびデータストレージ構造の要件も非常に詳細に記述されています。
仕様からのシナリオに基づいて、ユーザーの指示を準備することも便利です。これは、プロジェクトでお金を節約できるもう1つのポイントです。
おわりに
この記事では、プロジェクトチーム全体の作業の集大成であるターゲット製品とは何かに焦点を当てたいと思いました。 プロジェクトの結果が評価されるのはその品質です。 要件を実装するチームがコーディングに費やすのではなく、製品に直接実装する必要があるソリューションの必要な断片について情報を正しく認識し、ドキュメントを検索しようとする場合、要件がどれほど巧妙かつ美しく見えるかは関係ありません。
記事では、ソフトウェア製品の開発プロセスでの使用を最適化してより快適で適切にするために、最適なコンテンツ要件を選択する方法を個人的な経験からの例を示してみました。
このアプローチは、プロジェクトでのチーム時間のより合理的な使用により、プロジェクトのコストを大幅に削減できます。 私の経験では、プロジェクトの独自性と複雑さに応じて、1人のアナリストが3〜5人のプログラマに常に仕事を提供することができます。 同時に、開発者の生産性が大幅に向上し、実装の観点から予測可能性が高まります。 一方、チームでの作業結果の品質レベルはより均一になり、サポートのコストを最適化できます。
チームが要件を効果的に使用するという観点からのもう1つの重要なポイントは、実装段階でアナリストが彼の作業の成果を開発チームに転送するプロセスの正しい編成です。 しかし、このトピックは個別に議論する価値があります。
この記事は、提案された構成と要求仕様の形式の必須の使用に関するいくつかの推奨事項として解釈されるべきではありません。 各チームは、仕様を形成するための独自のコンセプトを開発する必要があります。 さらに、チームは、さまざまな主題分野および使用される技術プラットフォーム用の複数のテンプレートを持つことができます。 このようなテンプレートは、ソフトウェア開発プロセスの技術マップの形式で発行できます。
この記事では、私の著書「System Analytics ...ソフトウェア製品の設計」の資料を使用しました。