状況
- スタジオの入り口で、クライアント（事実上/実際には問題ではありません）。
- クライアントは、システム、ウェブサイト、アプリケーション、アプリなど、開発可能なすべてのものを注文したいと考えています。たとえば、アリクイでブルドッグを渡ります（1C Bitrix、ちょうど1C、他のシステムおよび開発）。
- 彼は何かを（私たちが見ているように）私たちに送り、それを "tz"（彼が見ているように）と呼びます-評価/カウント/質問し、そしてどこでも、非常に特定の正確な数と用語を受け取ることを期待して（例として）クリニック）準備ができたら。
- 待っています。
長年にわたり、私は販売ファネルのこの部分で実用的なデザインに来ました-私は常にそのような手紙に応答します-素晴らしい、私はそれを受け取りました、私は手紙で解決策の希望を見て、それを添付するのを忘れましたか？
この設計では、対話はあまり積極的ではなく、漏斗の次のステップへのスムーズな移行が常に行われます-TKとは何か、そこにあるべきもの、クライアントに他に述べる必要があるもの、特にクライアントに述べる必要のないものに関する積極的な対話、そして私たちはそれを行うべきです。
用語契約
- アーティファクトは、人間によって作成された何かの現実世界での物理的な表現です。
- アイデアは、顧客の頭の中にあるものです。
- 願いはデザインの成果物です。
- 要件-現実と一致する願い。
- 環境物理学-サイトの場合、これらはすべてw3cコンソーシアムに従って作成できるコンポーネントです。 モバイルアプリケーションの場合、これはApple開発者プログラムまたはandriod開発などです。
- アーキテクチャソリューションは、最終環境の物理要素を使用せずに、要件を実装するための口頭で定式化された提案です（具体的にはiPhoneやAndroidの画面についてではなく、画面について話します）。
- 参照条件-構成中のシステムの詳細な構成と、各要素およびコンポーネントの目的の特性のプロパティの説明、生産用のタスクドキュメント、および受け入れテスト用のドキュメント。
個別に飛ぶ-カツレツを個別に。
任意の計画の非常に短いライフサイクルと現実への実装を考慮してください。
- デザイン（何）->ワインが欲しい
- 願い（定式化）->ワインのボトルのメッセンジャーを送るかどうか
- 要件（マイルストーン）->ドライレッドフレンチ
- 建築ソリューション->レストランの樽から瓶詰めされたものではなく、瓶詰めされた家を消費します。
- 参照条件->店舗番号5で、2本のフレンチボトルをそれぞれ5ルーブルと交換します。
- 建設（生産、実行）->ショーを買いに行ってきました
- 領収書（検証）->オンデマンドで受け入れ、必要に応じて詳細をtkで検証します。
- 試運転->ボトルを開ける
- 操作->グラスに注ぎ、利益を消費します。
もう一度サイトまたはモバイルアプリケーションで：
- アイデア（何）->ビジネスを行えるスーパーサービスが必要だった
- 希望（定式化された修正）-> X、Y、Zを実行するサービスが必要
- 要件（チェックポイント）->サービスはX、Y、およびZを実行する必要があり、XおよびYでは不可能です。H。OK
- 建築ソリューション-> Xページとして行います。 Yはゲームのようになり、Hはフォームを介したリクエストのようになります。
- 参照条件-> X 5画面（描画）、24要素（マーク、すべてのデータが記述されています）、それぞれの目的（仕事から出る）、それぞれの行動シナリオ（クリック、勝つ、勝つ）、使用中の俳優（マネージャー、iPadの主婦）、結果などの実行から（情報が受信され、達成が完了し、手紙が送信され、製品情報が倉庫システムのアセンブリに転送された、など...）
- 構築（生産、実行）->コーディング、アセンブリ、技術仕様に従ったテスト、スクリプト実行。
- 受信（検証）->展開（運用環境、アプリストア、アマゾンへの展開...）
- 試運転->承認された作業、バナー広告、登録の送信。
- 操作->サービスが機能し、コンバージョンが増加し、キャッシュがレジに行きます。
誰が誰に何を負っていますか？
クライアントが通常述べることができることについて言えば、これらは常に願いであり、それらの一部（小さな部分）でもあります-専門家ではない人は、定義ではすべての願いを単に説明することはできません-彼のコンテキストではなく、彼はそれを理解するべきではありません。
明確にするために、クライアントの1人に1つの（！）要件のライフサイクルの図を示し、今日まで、質問に答えるために何をすべきかを示します。
計画がある場合は、仕事を始めるために頭から外す必要があります-彼らは私たちが望むものを理解し、それを書き留めました。 これらは願いです。 クライアントのデザインの成果物-これはクライアントのみが行うことができ、デザインは彼の仕事の一部です。
通常、計画は願いの形であり、誤ってそれを技術的タスクと呼んでポストに送信されますが、これは要件ではありません。
クライアントはどんなフォーマットでも願いを表現し始めます-現時点では多くのものを描いて巨大なプロジェクトを送ることはお勧めしません-それらのすべては単純な要件のリストから始めてとにかく開発に行くので、ただ時間を無駄にしないでください。
ホステスへの注意 ：請負業者の会社があなたの技術仕様を処理せずに生産に取り入れるという期待（突然、たとえば技術の詳細によく発達した技術の詳細がある場合-プロセスの一部になる）は、可能であれば、この会社のプロセスの品質についてのみ話す外から変化するので、目でランダムに動作します。
実践は、複雑な（追加という言葉から）複雑なプロジェクト（これは、企業のWebサイトから複数のシステムの複雑な実装まで、あらゆるビジネスシステムの開発または実装です）-エグゼキューターが結果の品質を保証するだけでなく、プロセスの品質と滑らかさであることを示していますが、そして一般的には、最終結果を取得し、予算をワイヤーで埋めることはありません。
一般に、技術的なタスクは本質的にはドキュメントであり、クライアントによるプロジェクトでの作業にとってはそれほど重要ではありません。いつでもシステムの要素のいずれかにアクセスして、どのように機能するかを確認し、宣言されたドキュメントの準備を受け入れる能力は重要です
この文書が請負業者の会社内での生産、および記載されたすべての要件と制限への準拠のために出力製品を管理するためにより重要である場合、これが品質を得る方法です。
技術的なタスクに対して私が提示した簡単なルールは次のとおりです。
参照条件
- 委託条件は
- 合意された要件とは対照的に請負業者によって書かれ、当事者によって署名されています。
- 参照条件には、ソリューション物理学の用語、運用環境で作成されたシステムの完全かつ包括的な説明が含まれており、質問に対する明確な回答を明確に示しています。
- 特定のユーザーの影響に段階的にどのように対応するか、システムのどの要素がどのように機能するかを正確に示します。
- 彼はどう見える？
- システム全体での目的は何ですか
- この要素が操作中にどのようにサービスされるか
- などなど。
- 結果を受け入れるための基準が含まれています。これは、システムの物理学の枠組みの中で、システムの特定の要素またはシナリオが正しく正常に機能することを明確に理解するためのものです。
- システムエンジニアリング要件の分野の専門家（資格を確認済み）と、システムとの相互作用の設計の専門家とのペアで記述されています。
要件について
要件-これはシステムの説明（モデル）であり、側では義務的モダリティの属性です。 （アナトリーレーベンチャック）
それとは別に、ビジネス要件はシステムの進め方に関する要求であることは注目に値します。
要件は、要件=欲望+正当化という単純な原則によって、願いとは異なります。
要件を正当化するには、要件が実際のニーズによって決定され、その実装によってプロジェクト全体のミッションと重複する（一致する）証拠のアーティファクトを提供する必要があります。
すべての要件は、3つの列の1つの大きなテーブルのリストに記録されます。
| 1.要件| 2.必要なもののために| 3.考えられる解決策|
二次的な要件やネストはありません-要件はシステムから外の世界への引き渡しのための特定の要件です-システムは特定の時点と場所で発行する必要があります。
要件は常に、システム関数の結果の出力と、システムのユーザーが操作する実世界への入り口にあります。
最も重要なことは、それが何をしているのかを示すことです（2番目の列でそれを示すようにお願いします。これは最も重要なことです）-要件はクライアントと一緒に書かれているので、私たちは常にこれを定式化するのを助けますが、時には多くの人にとって難しいプロセスです。
実際のプロジェクトの要件の例：
- カタログには商品が（目で）表示されている必要があります
- 物流システムは、配送を計画どおりに進めるために、ルート（紙、電子メール、目と脳へ）を発行する必要があります。
- トレーニングに関するSMSは電話（デバイス）に届く必要があります-全員に電話しないようにするためです。
- 製品ページは、特定の情報xyz（目で）を送信する必要があります-決定するために...
3番目の列では、ソリューションのビジョン-クライアントが自分の言葉でソリューションが機能することをクライアントがどのように見ているか-をこのサイトのようにします（これは通常起こります）。または、この部分を別のウィンドウで開くことを希望します。 すべてが青になります。
ソリューションのビジョンからの希望が非常に重要になった場合、それは「ソリューションの制限」と呼ばれるドキュメントのセクションに転送されます。
制限は常にソリューションを作成するプロセスを複雑にし、外の世界のニーズによって常に決定されるわけではないことに注意する価値があります。したがって、3番目の列にそれらを記述し、これがクライアントが特定の問題を解決するのにより快適で便利であるかのように、ある種のヒントであることを示しようとします。
これらすべてにより、クライアントの世界のオントロジーと私たちのオントロジーを同期させて、より明確に理解することができます。
要件がある場合-そしてすべてがマシン上で解決されます-プロセスは単純に実行されます。 すでに技術の問題があります-原則として、良いパフォーマーは錆びません。
要件は、常に相互に一貫しており、正当化が定式化され、その実現可能性がチェックされ、トレースが行われます。
要件を実証する必要があります-指からすべてを吸い取っていないこと。 文書、決定、その他の成果物はいつでも歓迎します。
要件トレースは、要件が作成された度合いとシステムコンポーネントへの影響を表示できるツールです。
この時点で、要件の影響度を理解できます。 要件が変更されました-構成が変更されました-また、トレースと影響の程度を示しています。
要件は当事者によって署名されます。 要件は簡単に変更され、作業の過程で絶えず補完されます。これは修正されており、作業を妨げることはありません。 要件はクライアントが作成します-契約者が同意し、当事者が署名します。
製品または機能を作成する利点を常に定式化する必要があるという事実についての一般的な誤解について話す場合、システムを運用および運用する作業の一部についてのみ話していることに留意する必要があり、ビジネス戦略またはビジネス要件については話したことがない。
ここdeppkind.livejournal.com/3259.htmlの Job Storiesで解決策を見つけることについてもう少し書きました。
したがって、需要と委託条件について話すとき、私たちは常に言う-利益ではなく、引き渡し。
参照用語の目的は、生産の開始と終了の基準点であることを理解する必要があります。
要件文書の目的は、要望を解決し、結果を管理することです。
あなたのTKが本当に単なる期待または未完の願いである場合-自問してください-十分に包括的な製品の生産からの出口をどのように制御しますか？
要件はどこで入手できますか？
- 座って書くことはまったく複雑ではありません。 要件はあなたの期待です。
- それが非常に難しい場合は、要件を注文することができます、誰がそれのためにいくらを取るか（これはあなたにインタビューし、誰もがそれをどのように、どのように行うかを決定します-私はスタジオでお金のためだけにそれを行います）、ここに秘書+タイピストの仕事のクロスがあります。 まあ、もちろん、私たちからの質問を制御します）
- 収集された要件について決定を下すことができます-ただし、各決定についてのみ、すでに価格と条件を設定できます。 5ルーブル、50リアムが可能です。 その後、誰かが市場で何かを提供します。あなたのニーズと状況は何ですか。
- 待って、請負業者に最も詳細な仕様を要求してください。
- 明確な理解が得られて初めて、システムは構造（開発）に入ることができます。
- それだけです。無料で（または個人的には料金の試験として）参照条件と要件に関するエラーの公開報告に取り組むことができます。
質問、コメントは大歓迎です。
見つかったタイプミスは修正され、新しいタイプミスが追加されます。