統合システムの機能要件の確認
おそらく、すべての開発者は、システムのすばらしい要件と不快な要件の両方に対処する必要がありました。 各業界には独自の仕様があり、普遍的な標準は紙でしか決定できません。 そして、これらの標準に従って実際の要件が記述されると、ページドキュメントを「何もせず」取得します。これは、せいぜい開発に干渉せず、多くの場合、ユーザーと顧客の実際のニーズに関して誤解を招きます。
したがって、この投稿では、特に統合システムの要件の定義に関する私の考えを簡潔に表現しようとします 。 考えを別の文脈で考えないようにお願いします。そうしないと、投稿はナンセンスに見えます。私はばかです。
統合システムの主な目標は、エンドシステムとユーザーに情報を提供することです。 この情報は完全で信頼できるものでなければなりません。 ユーザーまたはシステムに必要な形式で提示する必要があります。 彼女は時間通りに到着しなければなりません。 それは明確で仕事に十分でなければなりません。 したがって、コードの最初の行を記述するか、最初のアプリケーションをインストールする前に、いくつかの質問に答える必要があります。
なに？
ユーザーとシステムにはどのような情報が必要ですか？ 会計士は、すべての金融取引について知らされていない場合、働くことができません。 クライアントは、購入した商品のコストと特性がわからない場合、オンラインストアで購入することはできません。 配送サービスは、買い手の住所が提供されていない場合、どこにも持ち込みません。 そして、ゼネラルディレクターは、企業のすべての活動を明確に把握していない場合、少なくとも1つの適切な決定を下す可能性は低いです。 したがって、最初にすべきことは、誰がどの情報を扱う必要があるかを見つけることです。 慎重に見つけて、再度明確にします。
どこ？
必要な情報の入手先と提供場所 会計士はERPと連携しており、ERPのすべての詳細を確認したいと考えています。 ディレクターはレポートをExcelファイルで表示することを好み、購入者はオンラインストアのみを使用します。 彼らは誰も、さまざまな情報源を整理したり、明確な電話をかけたり、電子メールで詳細を調べたりすることを望みません。 使い慣れたインターフェイスで必要なものすべてを取得したいと考えています。
いつ？
すべてのデータを収集して、エンドユーザーまたはシステムに提供するだけではいけません。 私たちは時間通りにそれをしなければなりません。 四半期レポートの作成に必要なデータが数日間遅れると、それらは完全に不要になります。 クライアントが商品の価格と在庫数を確認する前に数分待たなければならない場合、おそらくより効率的な競合他社に行くでしょう。
「いつ？」という質問には、両方の方法で機能する時間厳守規則が適用されます。 つまり データは遅れるべきではありませんが、これが必要でない場合、事前に送信することはできません。 いいえ、明日だけに必要なものを今日見つければ、悪いことは何も起こりません。 しかし、情報を送信する必要がある頻度、その実際の量、応答性がどれほど重要であるかなどを明確に理解しています。 適切な統合テクノロジーを選択するための鍵です。 そして、間違ったテクノロジーは、予算超過、プロジェクトの「取り壊された」条件、非常にフェッチされたアーキテクチャ、およびどこにでもある「クランチ」です。
これら3つの基本的な質問に回答し、（最も重要なことですが！）ドキュメントのすべてを修正したら、アーキテクチャと応用技術について考え始めることができます。
ルールに従って、「システムの機能要件」はこれらの質問に答えなければなりません。 また、「FT」または「要件の仕様」でもあります。 異なる企業では、この素晴らしいドキュメントは異なる呼び方をするかもしれませんが、本質は同じです-それはシステムが実際に何をすべきかを決定し、なぜそれを必要とするのでしょうか？ したがって、FTがこれらの3つの魔法の質問に答えない場合は、安全に捨てることができます。 そのようなドキュメントのアーキテクチャを開発することは不可能です。 商品の注文プロセスがどの程度詳細に記述されていても、管理パネルのボタンがどれだけ美しく描かれていても関係ありません。文書はその目的に対応している必要があります。 そして、彼に提起された質問に答えるために。
PS
そして、はい、誰かがFTを書くとき、忘れないでください-プログラマーが役に立たない文書を受け取るたびに、彼は小さな白いウサギを痛烈に殺します！