しかし、ソフトウェア開発のお客様からは、要件の既製の仕様を受け取ることを期待しています。
製品開発、特にスタートアップでは、製品ライフサイクル全体で要件の生成が均等に分散されているため、状況はわずかに改善されています。 Lean StartUpの原則：ビルド->測定->学習のおかげで、製品チームはより短いサイクルで作業できます。 各反復の入り口には、「実験」の要件の新しい部分があり、その策定にはチーム全体が関与することがよくあります。
カスタム開発では、クライアントからの既製の要件を待つことに関連する3つのタイプの問題を観察します。
- 「ビジネス」は、開発プロセスと技術的能力を理解していないため、適切な要件を策定する方法を知りません。 仕様には、ドキュメントの最後まで到達するのが難しい問題を解決するという顧客の考えが含まれています。
- 「ビジネス」には、要件を解決するのに十分な時間がありません。 システムを使用するためのいくつかのオプションは、事前に考え出されたものではなく、開発中にスローされます。 反復プロセス（CI、自動テスト、作業中の機能の数の制限）をサポートするプラクティスが少ないほど、要件を変更することは難しくなります。
- 「ビジネス」と「開発」は異なる言語を話します。 その結果-要件の誤った理解、デモンストレーションの時点でそれらが「驚き」から生じる不明確な仮定。 存在しないシステムは、紙で説明することは困難です。 したがって、顧客が要約できる問題は、「自分が何を望んでいるのか正確にはわかりませんが、何を望んでいないのかは正確にわかります」です。
ビジネスと開発の両方の当事者がこのプロセスに関与している場合、問題の定式化と技術的解決策の検索の両方がより簡単で効果的であることは明らかです。
製品のアイデアで燃えているクライアントをどのように支援できますか？ビジネスと問題の言語で明確にそれを定式化します。 不必要で時期尚早な詳細な要件を課すことを避ける方法は？ 市場、ユーザー、要件の価値、実装の成功基準を理解するための時間を短縮するにはどうすればよいですか？
以下に役立つ製品テクニックの概要を示します。
- ユーザーペルソナこのツールは、ユーザーの問題とタスクに最大限に焦点を当てるために、開発者がインタラクティブデザインから借用したものです。 Description Personは、開発チームが主要なユーザーグループのニーズを理解し、人口統計データ、ライフスタイル、およびその他の一般的な特性に基づいて要件を策定および実装するのを支援します。
- インパクトマッピングこれは、ビジョンの構築に役立つ戦略的計画ツールであり、開発中に「機能スープ」で失われるのを防ぎます。 影響マップには、次の反復のビジネス目標が含まれており、チームがそれらに従って目標を決定するのに役立ちます。 また、機能に関する誤解や誤った仮定から保護し、開発への深刻な投資を必要としない代替実装のアイデアを生成するのに役立ちます。
- ユーザーストーリーユーザーストーリーの形式での要件の説明の形式は、ビジネスと開発の間のより詳細な対話の優先順位付け、保存、および「招待」に便利です。 このような対話は、JITの原則（「ジャストインタイム」）で、つまり、機能の開発に関する決定を下すべき時点で行われるべきです。 これにより、実装する必要のない要件の詳細な調査に多くの時間を費やす必要がなくなります。 この形式は、ビジネスの言語を使用し、製品/リリース/イテレーションのビジョンと目標に開発者の焦点を維持するために、要件の人とビジネス価値に関する情報を含みます。
- ユーザーストーリーマッピングユーザーの種類と製品との相互作用のシナリオを記述する高レベルの要件モデルを取得できるアプローチ。 カスタムストーリーマップの作成は、製品開発を開始する前のブレーンストーミングの一種です。 ただし、このツールを使用してリリースを計画し、それに含まれる機能を選択できます。
- 狩野重み付け 5つの満足度基準に従ってユーザー設定を分類する「重み付け」要件の手法。 質問に答えるのに役立ちます-製品配送（MVP）の最小貴重量とは何であり、次の反復で実装するための機能を選択します。
- User Story Hamburger要件を分解するためのツール。実装の技術的な詳細を視覚的に議論し、美しさ、複雑さ、コストの観点から最適な方法を選択できます。 配信を促進してフィードバックを得るために、複雑なストーリーを単純なストーリーに分離するのが困難な製品所有者および開発者に役立ちます。 また、ビジネスパーソンの観点と開発者の観点の両方から、「合理的に優れた」ソリューションの明示的な議論にも役立ちます。
- 例による仕様要件の定式化と管理のプロセスに影響を与える受け入れテスト組織ツール。 これにより、ビジネスユーザーと開発者の相互作用を改善し、製品の品質を改善し、機能の処理を減らし、誤った仮定に基づいて「アイドル」開発を行うことができます。
リンクから各手法の詳細情報を見つけることができます。それらの存在に注意を喚起したかっただけです。 これらのツールを実際に適用する際の問題については、個別の記事または個人でお伝えできることを嬉しく思います。