既製の要件の編成について話します（要件はすでに受け入れられ、定式化されており、現在、それらで作業が行われています）。 このコンテキストでは、要件とは、特定の機能（私の場合はサイト）を、開発者、顧客、単なる人間に理解できる言語で記述し、どのように機能するかのアイデアを与えることです。
以下に記載されているのは究極の真実ではなく、開発チームが日常的に要件を処理する際に直面する問題と、それらを解決するためのツールの説明にすぎません。
これらすべての必要性はどこから来たのですか？ なぜこれだけなのですか？
要求組織システムを作成するというアイデアは、ロシアのインターネット小売業者のプロジェクトでの作業に現れました。 オンラインストアの小売Webサイト（私が販売している場所、おむつ、そば、衣類、チケットなどすべての言葉を恐れていません）に加えて、企業クライアント、あらゆる種類のサービス、ブランドゾーンと連携するためのプラットフォームでもあります。 これらにはすべて独自の要件があり（ほとんどは独自のビジネス顧客がいます）、どこかで説明、保存、処理し、問題を解決する必要があります。 キー（もちろん、もっと多くありますが、以下のリストが最も関連性があります）。
1.タスク（分析、開発、テスト）はさまざまな人によって実行されるため、非参加者はいつでも要件を明確にし、内容を理解する必要があります。
2.要件は絶えず更新されます。→既存の要件を迅速かつ明確に変更するメカニズムが必要です。
3.サブプロジェクトの要件は、小売サイトの要件を参照→シンプルで明確なドキュメントの編成が必要であり、常に機能するリンク。
最初のポイントは詳細である必要はないと思います-すべてはすでに明確です。
要件は常に更新されています
明らかなように思えますが、サイト上の変更は、変更が関係するブロックに加えて、他の機能に影響を与える可能性があります。 これを見失わないことが非常に重要です。 したがって、変化する機能に関連する機能のリストが目の前になるようにドキュメントを整理する必要があります。
そしてもう1つ、たとえば、ユーザースクリプトで何も変更がなく、データ交換スクリプトだけが変更されることがよくあります（サイトユーザーは何も感じないでしょう）。 ただし、すべてを1つの要件（ユーザースクリプトの要件、データ交換スクリプトの要件、ユーザーインターフェイスの要件）に含めると、ほとんどすべてが相互接続されます。 その結果、システムシナリオのみに変更を加えると、すべてに影響します;変更は1つの大きな需要に適用されます-それは不便です。 したがって、私はすべての要件を粉砕することに賛成です。 方法-以下で説明します。
サブプロジェクトの要件は小売サイトの要件を参照
ここでのポイントは何ですか。 人生の簡単な例で説明しようと思います。
オンラインストアが提供するサイズと機能に関係なく、オンラインストアがオンラインストアではなくなる基本的な機能があることは明らかです。 たとえば、チェックアウト機能。 （注文する機能がなければ、これはオンラインストアではなくカタログになります。）そして、この機能はサイト全体に実行されます。 そこで、私たちはサイト上でサードパーティのサプライヤーから直接商品を購入できるようにしました-個別のサブプロジェクト、個別の要件。 しかし、ここには注文を出すプロセスがあります。これは一般に、通常の商品と同じです。 そして、私たちは何をしていますか？ 私たちはただ書きます： 小売サイトの要件「-リンク。 新しい要件を記述する必要はありません-時間を無駄にし、ドキュメントに配置します。 利益
しかし実際には、この方法には危険がたくさんあります。 上で書いたように、要件は絶えず変化しています：一部の機能は更新されており、何かを放棄しています。多くの場合、要件はすぐにサイトに移動し、ドキュメントで分析をバイパスします。 その結果、開発者はサイトで1つのことを開発し、ドキュメントでは別のことを言います-3番目のことです。
そして、何が起こりますか？
開発者は「小売サイトに似ています」。 ビジネステストの時が来ました。 顧客は何を見ていますか？ メインサイトでは、彼のプロジェクトとは異なります。 そして結局のところ、誰もがこれがメインサイトのようであるべきだということを理解しています。 しかし、メインサイトの開発時にそれをどのように説明するのですか？ そして、評価はそのような実装のためにそのように与えられました （その時他にありませんでした）？ その結果、やり直す必要があり、これはすべての参加者の不満は言うまでもなく、新しいコストです。
もちろん、サプライヤとのプロジェクトの枠組みでは、リンクの代わりに、小売サイトの現在の機能を簡単に説明できます。 しかし、これ：
1）複製（機能の要件を更新する必要がある場合は、これに加えて、更新時に触れておく必要がある別のドキュメントのもう1つのポイント）
2）文書内のさらに多くのテキスト（とにかく文書は非常に面白い文献と呼ぶことはできません-それが非常に大きい場合、無意識に不快感を感じ始めます）、
3）これは、より多くのテキストから情報を抽出する必要があることを意味します。
あなたは簡単に言うことができます：「それがサイトでどのように行われているかを見てください-ここでも」。 ただし、実装の評価が行われてから実装が開始されるまでの間に、サイト上で何かが変更された場合、評価は現実に対応しなくなります。
そして、何をすべきか？
上記の問題の解決に役立ついくつかのツールを強調しました。 以下に、コメントと写真付きのリストを示します。
まず、 すべての要件を目的に応じて分割する必要があります 。
1.ユーザーシナリオ：サイトでの作業がサイトユーザーをどのように探すか。
2.システムシナリオ：ユーザーがサイトで作業するときにサイト内で何が起こるか-データ交換シナリオ、計算、内部アルゴリズム。
3.ユーザーインターフェースの要件：サイトのユーザーインターフェースのオブジェクトの動作、ソース、制限-話している要素（テキストフィールド、ポップアップ、ドロップダウンリスト、フレームなど）に応じて。
まず第一に、それは便利です。テスターにとって、テストスクリプトを作成するには、ユーザースクリプトのみを読む必要があります。 ビジネスのお客様は、それらとユーザーインターフェイスの要件に同意します（これが機能し、内部で行われる方法のアイデアに従ってサイトを確認することが重要です-決定するのは技術専門家次第です）。 デザイナーに似ています。 しかし、アナリストは、これがどれほど実現可能かを理解するために、システムシナリオも必要とします。 彼らによると、サイト開発者は、サードパーティのシステムの代表者とインターフェイスを調整します。 等
第二に、内部システムのシナリオのみが変更されるという状況が発生すると（上で書いたもの）、変更されます。すべてが詰め込まれ、それを書き換えるという大きな要件を満たす必要はありません。
以前は、3つの関連ドキュメント（ユーザースクリプト、システムシナリオ、ユーザーインターフェイス要件ドキュメント）、または少なくとも1つのドキュメントの異なるセクションに3種類の要件を保持するのはクールだと思っていました。 そして、それは正しいようです。 このメソッドと要件の組み合わせは、要件コードを犠牲にして行われます（以下で要件コードについて説明します）。 しかし、限られた時間の条件では、3種類の要件すべてを1か所で開始する方が簡単です。
したがって、私は柔軟性のためであり、ルールを盲目的に従うためではありません-便利なオプションを選択する必要があります（要件は開発者、テスター、および適切な技術的背景のない人々によって読まれることを忘れます）。 考えられる結果を考えます（今はもう少し努力する方が良いかもしれませんが、必要なものは少なくなります）。
第二に、 各要件には独自のコードが必要です 。
誰もがそうであるように、これは理解可能で論理的です。 私はこの問題についてもう少し進みました-私は反映しようとするリクエストコードで：接続、バージョン、いくつかの追加データ：
システムユースケースである「 TECH 」ではなく「 SUC 」を使用する方が正しいですが、顧客はそれを誤って認識する可能性があります（略称がBR EDであるため、何らかの理由で既にリクエストコードの名前を変更するよう求められました）。
4列目-CR-これはまったく同じ「何らかの追加データ」です。 この場合、管理者が必要とするデータは、メインスコープのフレームワーク内で要件に変更が加えられたかどうか、または別のお金のために変更されたかどうかを理解するために必要です。
また、このバージョンは、「メインサイトと同様に」行われたときの状況から美しく抜け出すことを可能にするものであり、テストの時点でメインサイトは変更されています。 次に、私の意見では、同じ場所でバージョンについて要件を作成するのがいかにクールかを説明します。
それ以外の場合、写真では、すべてが非常に明確に反映されているように見えます。
第三： 要件の登録 。
私はこのようにします：
要件コードについてはもう少し上に書きました。
関連する要件には同じ機能を説明する要件コードが含まれていますが、たとえばデータ交換の観点からは（要件を3つのタイプに分割することを要求したときに言ったこと）-したがって、関連する要件の要件コードは同じである必要があり、タイプ部分を除く。 名前も異なる場合があります。
子要件は、既存の要件の拡張です（この例では、これは説明されている要件の一部として利用可能になるiFrame要件です）。 「親要件」フィールドを追加できます。それに応じて、要件コードが表示され、その拡張子は説明されている要件です（fuh！）。
ERPおよび支払いシステムのフィールドはオプションです。ERPおよび支払いシステムが説明されている要件で言及されている場合にのみ必要です（そうでない場合、フィールドはまったく必要ありません-なぜ追加情報を生成するのですか？）。 ちなみに、これは承認の段階では非常に便利です。さまざまなシステムの代表者がドキュメントに同意する必要がある場合、ドキュメント全体を読む必要はありません。作業に影響する要件に限定するだけで十分です。
ここに「レイアウト」フィールドが存在する場合は追加し、そこへのリンクを表示できます（開発者は感謝します）。 Jiraのタスク（Redmineなど）にリンクを追加できます-一般的には、必要なものは何でも。
次はバージョンセクションです-私の意見では、重要なブロックの1つです。
彼と仕事をする方法とその本質は何ですか？
要件の変更が到着すると、次のようになります。
1）要件はライターによって（論理的に）変更されます。
2）「バージョン」セクションに新しい行が作成されます。ここで、
- バージョンコード-変更された要件のコードとバージョンの作成日。
- ソース-この変更をどこから（手紙、通信、タスクなどから）取得したのか-何が変更されたのか、誰が、どの瞬間にイニシエーターになったのかを把握する必要がある場合に役立ちます。
- 新しい意味は、需要が変化したことです。
別のドキュメント（サブプロジェクト）から要件を参照する場合、参照する要件のバージョンを既に示しています。 感じますか 感じますか
- サブプロジェクトの要件の開発者は次のように読みました。 小売サイトの要件のバージョン。」
- 開発者は、指定されたバージョンに従って評価し、実行しました。
- 小売サイトの要件が変更されました-サイトが変更されました。
- 開発者によって実装されたサブプロジェクトの機能をテストする番が来ました。 実装は期待されたものと一致しませんでした。 しかし！ 開発者は実装時に関連していた小売サイトの特定のバージョンによって導かれたため、変更が計画されていない場合でもこれが実現されたという理解があります。 そして、何かを修正する必要がある場合、これは新しいタスクの一部として行われ、バグを修正するのではありません。 それで！
おわりに
私の会社でこのトピックに関するプレゼンテーションを行ったとき、最初の質問は次のとおりでした。要件を作成するだけで無駄な時間はありませんか？ しかし、これはドキュメントのサイズを不当に増加させることはありませんか？ 顧客が要件のバージョンについて読む必要があるのはなぜですか？
だから、時間はあまり費やされていませんが、はい-費やされています。 しかし、私自身にとって、この利点はわずかな時間を費やす価値があると判断しました。 そして、はい、それはドキュメントのサイズを増やします。 それを減らすために、特定の要件を処理するのに必要なフィールドのみを使用します（冗長な情報を避けるようにします）。 はい、顧客はこのリスト全体を必要としません（さらに、開発者、ライター、テスターも）。 しかし、サイトが要件に関連する何かを変更し始めるまで、または特定の変更を実装（評価、テスト）するように求められるまで（何？-答えは要件のバージョンにあります）。
各プロジェクトの作業には微妙な違いがあり（実際、プロセスはどこでも異なる）、明確に推奨事項に従うのではなく、そこから自分にとって役立つものを抽出することが重要です。 受信した情報に基づいていくつかのアイデアを生成することが可能です。 私は問題を解決するためにそもそも使用されているシステムです-あなたがあなたの仕事を妨げる毎日遭遇する特定の問題 。 そして、何かを実装する前に、「なぜ？」、「これでどのような問題を解決しますか？」（半分の哲学）という質問をする必要があります。
私の仕事では、Googleドキュメントを使用しています。 この作業には多くの利点があります（ここではそれらをリストしません）が、ドキュメントを整理するという観点からは、最初の要件は要件内の要件へのリンクを配置するのに便利で、2番目はドキュメントの変更履歴の比較的便利な表示です。
上記のシステムは絶えず変化し、改善されています（新しい問題が発生したため）。