この標準はソフトウェア要求仕様の考えられる構造、望ましい目次、品質などについて記している。関係者の特定[編集]1990年代になって特に強調されるようになったのは、「関係者」の特定である。「関係者」とは単にそのシステムを発注した企業の社員だけに限られない点に注意されたい。中で、要求を集める作業をユーザーが妨げる可能性を以下のように示した:ユーザーは自らが何を欲しているか理解していないことがある。ユーザーは要求仕様書に関わりたがらないことがある。ユーザーは既にスケジュールと費用が確定した状態で新たな要求を出してくる。ユーザーとの対話には時間がかかる。ユーザーはレビューに参加したがらないか、参加できないことがある。ユーザーは技術に疎い。ユーザーは開発工程を理解しない。このような要因によって要求仕様は開発が開始されてからも変更され続けることになる。技術者/開発者の問題[編集]要求分析において技術者や開発者が次のような問題を引き起こすこともある:技術者とエンドユーザーは語彙の違いによって話が通じないことがある。結果として意思疎通できていないにもかかわらず、完全な合意に達したと勘違いしたまま開発を行うことがある。技術者や開発者は要求を既存のシステムやモデルに当てはまるようにしようとする傾向があり、その顧客専用のシステムを開発するのを避けようとする。分析を技術者やプログラマが行ってしまい、対象分野の専門家が参加しないためにユーザーのニーズが正しく反映されないことがある。解決の試み[編集]このような意思疎通問題の解決策としてそのビジネスの専門家やシステム分析の専門家が雇われることもある。1990年代に登場したプロトタイピング、統一モデリング言語(UML)、ユースケース、アジャイルソフトウェア開発などの技法も従来の手法の問題点を解決するべく導入されてきた。アプリケーションのシミュレーションツールや定義ツールも市場に出回るようになってきた。このようなツールはユーザーとIT組織の意思疎通問題を解決するよう設計されており、実際にコードを開発する前にアプリケーションを試してみることを可能にしている。これらツールの特徴は以下の通り:電子ホワイトボードでアプリケーションの流れを図示したり代替案を検証する。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスのもとで利用できます。追加の条件が適用される場合があります。詳細については利用規約を参照してください。Cookieに関する声明モバイルビュ。