暗黙の要件を処理する適切な方法は何ですか？

新しいソフトウェア製品の研究開発をしています。

経営陣は当然のことながら、明らかに顧客に利点をもたらす主要機能に焦点を当てています。しかし、同様に重要と見なすことができる多くの要件があります（例：パフォーマンス、将来の拡張性、データのトレーサビリティ、セキュリティ、スムーズなUI）。これらの暗黙の要件は、おそらくすべての製品の数が多く、満たされていない場合、顧客を不幸にする可能性があります。

どういうわけか、開発中にこれらのものが自動的に実装されるようになることが予想されます。私にとっては、すべてがそれ自体の注意と開発努力を必要とする原子的な側面です。

経営が忙しくて、そういうところに目が行き過ぎているのではないかと感じています。開発者の誇り、品質管理、および費やした労力を説明できるようにするために、暗黙の要件をいつどのように文書化して伝達する必要がありますか？

（つまり、製品に存在するが、顧客または管理者のいずれとも明示的に話し合われていない機能）

明確化

質問に関心をお寄せいただきありがとうございます。これまでの回答の主な要点は次のようです。

「暗黙の要件を明示的にする必要があります。」

ネズミ...それは私には起こりませんでした。

私が意味する要件には、次のタイプがあります。

• お客様がこれらの要件について聞くことはできません。私は、製品がどのように満足するかについて話すのではなく、製品が失敗する可能性がある方法の長いリストを提示するからです。
• 忙しい経営者は、「明白な」機能について話すとき、私は彼らの時間を浪費していると感じています。
• 実装中は、これらの要件の一部のみを説明できます。計画中、特定の問題は開発中に集中的な努力を必要とするかもしれないと直感するだけかもしれません。
• 会社のトーテムポールで必要な高さではなく、自分の労働条件を決定している。

本格的な要件よりも労力をかけずに、[暗黙の]要件をセミフォーマル化する方法のガイドラインを求めていますが、判断の準備をしているので、手ぶらで捕まることがありません。

暗黙の要件を明示的にすることが正解です。

フォローアップの制約について：

お客様がこれらの要件について聞くことはできません。私は、製品がどのように満足するかについて話すのではなく、製品が失敗する可能性がある方法の長いリストを提示するからです。

あなたが建築家で、大企業の建物を設計していると想像してください。

Big Co. Inc.は海岸沿いにスカイスクレイパーを構築するように求めています。屋上にスイミングプールがあり、10階に別のプールが必要です。15階から17階までの外壁を覆うウォールガーデンが必要です。

これはお客様の要件です。要件リストに、建物が自重をサポートするための要件に加えて、水で満たされた2つのプールとヒューズウォールガーデンを追加することをためらいますか？

配管、電気配線、プールを水で満たし、水をきれいに保つためのシステムが必要であることを付け加えるのをためらいますか？

あなたは建築家であり、あなたは建物に何が必要か、それが彼らがあなたに支払うものだと知っています。

3階以上ある建物にはエレベーターが必要であることはご存じでしょう。そのことを誰かに教える必要はありません。

忙しい経営者は、「明白な」機能について話すとき、私は彼らの時間を浪費していると感じています。

したがって、エレベーターは明らかです。明らかなように、それは依然として全体的なコスト、必要な全体的な労働力、プロジェクトのETA、そしておそらく他の側面に影響を与えます。

実装中は、これらの要件の一部のみを説明できます。計画中、特定の問題は開発中に集中的な努力を必要とするかもしれないと直感するだけかもしれません。

これは、主にITの流動性のために、アーキテクトのアナロジーが崩れるところです。ここでの唯一のアドバイスは、計画外の計画を立てることができる反復プロセスから利益を得ることができるということです。アジャイルはかなり人気があるようです。

会社のトーテムポールで必要な高さではなく、自分の労働条件を決定している。

あなたの会社には、要件リストが完全であることを確認する責任がある誰かがいるはずです。

• 彼らが大きな問題を抱えていない場合は、彼らにそれを修正してもらうか、履歴書を磨いてみてください。
• 彼らはそうするが、その人は彼の仕事を正しくしなかった場合、それに電話をかけ、必要に応じてエスカレーションします。
• 彼らがそうし、その人があなたであるが、あなたがあなたの仕事をする権限を与えられていない場合、彼らはあなたに何か不可能なことをするように頼んでいます、あなたの最善の動きは遊ぶことではありませんあなたの履歴書を磨き始めます）。

すべてを定義します。そうすることの唯一の潜在的な欠点は、あなたが明白なことを述べていると彼らが感じていると不平を言う何かを取り戻すかもしれないということです。

次に明白なことを述べなさい。

これが鍵です：定義していないものは、「あなたは私たちに言わなかった...」であなたの顔に投げ戻される可能性があります。

定義されていないものは、あなたの顔に爆発する可能性があります。「申し訳ありませんが安全です」という言葉は、生きるための優れた言葉です。

このような要件を表す業界用語は次のとおりです。

非機能要件

それらは、あらゆる側面で技術リソースによって識別され、アトミックな作業単位としてプロジェクト計画に追加される必要があります。アジャイルプロジェクトを実行している場合は、ユーザーストーリー形式で記述され、バックログに追加されて処理されます。テクニカルリソースとして、これらに取り組む時間を提唱し、ビジネスとのスプリント計画またはプロジェクト計画セッション中にそれらが適切な優先順位を持っていることを確認する必要があります。さらに、QAはこれらの作業単位に対しても適切なテスト計画を作成する必要があります。

たまたま、これらの暗黙の要件のいくつかは定義されていないために私たちに噛み付いたため、QAはそれらをテストせず、バグが本番環境に行き、しばらくの間見つからなかったため、顧客に説明するだけでなく、問題とそれが以前に発見されなかった理由ですが、私たちの会社の実際の法的問題です。（政府に報告しなければならない情報を扱った報告でした。）

十分に重要な場合は、テストする必要があるため、要件の一部にする必要があります。

要件は、それらがどこから来たのか追跡可能であり、互いに矛盾していない限り、どのソースからのものでもかまいません。顧客は要件を提供できますが、要件は法律、規制、業界標準、ビジネスニーズ、さらには類似の製品を他の顧客に提供することで学んだ以前の経験からも生じます。

これらの各要件は、要件をキャプチャするために使用する方法でキャプチャされ、忘れられないようにする必要があります。これを行うことで、それらを比較して、追加された要件が実際に顧客の要件と競合していないことや、顧客の要件が規制と競合していないことを確認できます。

これらの要件を把握し、プロジェクトの最初から直接管理し、ソフトウェアの設計、実装、およびテストを行うスタッフにそれらを流す必要があります。これを行うことで、配布されたソフトウェアがどうあるべきかを誰もが完全に理解できるようになります。

ただし、これらの要件の1つを追加する場合は、適切な関係者に確認する必要があります。意図したスケジュールと予算内でソフトウェアを提供できることを確認せずに、要件を単純に追加することはできません。

これは、さまざまな分野を専門とする人々が参加する多様なチームが参加する場合です。また、より多くのSRが必要です。残りをリードするチームの人々。

たとえば、パフォーマンス、将来の拡張性、データのトレーサビリティなどは、最初から考えるべきことです。これらは、戻って後で追加できるチェックボックスではなく、デザインの基礎にある必要があります。

セキュリティに関しては、これは、この領域に精通している誰かが最初からチームにいて、設計プロセスを手伝ってもらうときです。

UIのデザインは、適切に行わないと製品に食い込む傾向があります。チームのUX担当者がチームのモックアップと画面フローを行うことは、これが効果を発揮する場所です。しかし、これもまた、前もって行う必要があることです。

要件としては、ユーザーがローカルストアの現在の在庫を検索できるWebサイトが考えられます。そのシステムをどのように設計するかは、これらの暗黙の要件が関係する場所です。

これは、プロジェクト管理の観点からは、予算内に設計時間と適切なテスト時間が必要であることを意味します。また、クライアントにチェックインして、正しい方向に進んでいることを確認するために何が行われたかを示す必要もあります。

最終的にチームの作業の原因となる暗黙の要件は、明示する必要があります。
そうでない場合、彼らはどちらかになります

1. 人々がとにかくそれらを育てたときに後であなたを噛んで、開発のオーバーランを引き起こします
2. 無視され、後でバグとして報告される
3. いずれにせよ、実装されていなかったにもかかわらず、スケジュールされていなかったため、オーバーランやバグレポートが発生しました。

したがって、暗黙の要件を明示的にすることで、多くの頭痛の種を省くことができます。