フリー百科事典『ウィキペディア(Wikipedia)』この記事には参考文献や外部リンクの一覧が含まれていますが、脚注によって参照されておらず、情報源が不明瞭です。脚注を導入して、記事の信頼性向上にご協力ください。analysis)とは、システム工学やソフトウェア工学において新たなシステムやシステム更新に際しての調査/定義に関わる工程を指す。要求分析はシステム設計工程でも重要な部分であり、アナリストやシステムエンジニア/ソフトウェア開発者が顧客の必要性や要求を特定する工程である。顧客の要求が特定されたら、システム設計者がその解決策を設計することになる。顧客やユーザーとの対話によってその要求を聞きだす。要求を必要に応じて明確化し、補い、矛盾点や問題点を明らかにする。文書形式には通常の自然言語の文書以外にユースケース、ユーザーストーリーなどがある。要求分析は時間のかかる忍耐を要するものとなる場合もあり、微妙な心理学的スキルを要することもある。新たなシステムは人間関係や環境を変えることもあるので、関係者全てを特定しておくことも重要であり、関係者全員のニーズを聞き出すと共に、彼らがシステムとどう関わるかを理解していることを確認する必要がある。アナリストは顧客から要求を聞きだすためにいくつかの技法を活用する。インタビューやフォーカスグループ(要求ワークショップ)から要求リストを作成するのは古くからある技法である。新しい技法としてプロトタイピングとユースケースがある。必要に応じてアナリストはこれらの手法を駆使し、関係者の要求を正確に把握する。それによってビジネスの必要性に合ったシステムが開発される。関係者インタビュー[編集]関係者インタビューは要求分析の典型的な手法である。工数との兼ね合いで関係者の選択が一般に必要とされる。インタビューによってプロジェクトの開始時点で想定していなかった要求が明らかとなり、個々の要求の間で矛盾が生じることがある。要求ワークショップ[編集]場合によっては関係者を集めた「要求ワークショップ」を開くのが有効である。ワークショップは関係者が集中できる環境で行うのが望ましい。司会役は議論が逸れないよう注意する。書記役が議論を記録しておくのがよい。司会役はプロジェクターと図作成ソフトウェアを使ったり、紙とマーカーによる資料を使ったりする。司会役の重要な仕事として、個々の要求の優先順位付けが参加者の個性にあまり依存しすぎないように注意しなければならない。契約型要求リスト[編集]要求を文書化する方法として契約型要求リストがある。複雑なシステムでは、この要求リストが数百ページにもなることがある。検証可能な目標[編集]最善のプロジェクトでは、要求リストを単なる手掛かりとして扱い、繰り返し「何故このような要求が出てきたか」を問いかけて真のビジネスの目的を明らかにする。関係者と開発者で各目標の達成状況を測るための基準を設ける。これら目標は個別の(基準のない)要求リストよりも変化しない。重要な目標が達成されたとき、手早いプロトタイピングと開発によってプロジェクトの途中であっても関係者に成果として提供することがある。プロトタイプ[編集]1980年代中ごろ、要求分析問題の解決策として「プロトタイピング」が注目された。プロトタイプとは、開発前にユーザーに対してアプリケーションを視覚化してみせるための画面表示などである。プロトタイプによってユーザーはシステムがどのようなものかを具体的に描くことができるようになり、開発前に設計上の決定を行うことが容易になる。プロトタイプの導入によってユーザーと開発者の対話が大いに改善された。最初に画面の見え方を示しておけば後工程での変更が少なくなり、全体としてコスト削減につながる。その後、次のような問題は解決できないことがわかってきた:マネージャから見れば、プロトタイプが即座に出来てきたのに、実際の開発に時間がかかる理由が理解できない。設計者は実際の開発にあたって一からやり直すことになるのを恐れて、プロトタイプのコードをつぎはぎして実システムを作ることを強制されているように感じる。プロトタイプはユーザーインターフェイスの設計などには有効である。本来の要求が何だったのかということとは無関係である。設計者とユーザーがユーザーインターフェイスの設計に重点を置きすぎて、実際にビジネスを行うシステムがおろそかになる。プロトタイプは、実際に動作する簡単なアプリケーションの場合もあるが、線画(ワイヤフレーム)の場合もある。線画では色をつけないようにして、最終的なシステムの見た目と混同させないようにするのがよいとされる。ユースケース[編集]→詳細は「ユースケース」を参照ユースケースは、新システムやシステムの改善にあたっての要求を文書化する技法である。各ユースケースは1つ以上の「シナリオ」を提供し、その中でシステムやエンドユーザーや他のシステムがどのように相互作用を行ってビジネスの目標を達成するかを描く。ユースケースでは技術的な専門用語を排し、エンドユーザーやその分野の専門家にわかる用語を使うのが望ましい。ユースケースはソフトウェア開発者とエンドユーザーが共同で執筆することも多い。ユースケースはソフトウェアの挙動を説明する単純なツールである。ユースケースにはユーザーがインターフェイスを通してソフトウェアを動作させる全ての方法に関する文章による記述が含まれる。ユースケースはソフトウェア内部の動きは記述されないし、どう実装されるかも説明されない。ユーザーが何かをソフトウェアにさせる際の手順を示すだけである。このような形で全てのユーザーとシステムのやり取りが記述されている。1990年代、ユースケースは機能的要求仕様を捉える手法として急速に広まった。その起源となったオブジェクト指向の世界で顕著であるが、その利用はオブジェクト指向システムに限られたものではなく、ユースケース自体はオブジェクト指向に縛られた手法ではない。各ユースケースは1つのビジネス目標/タスクを達成する方法を描いている。従来からのソフトウェア工学の観点からすれば、1つのユースケースはシステムの1つの機能を描いていると言える。多くのソフトウェアプロジェクトでは、システム全体を記述するのに数十から数百のユースケースが必要であることを意味する。特定のソフトウェアプロジェクトの形式化の度合いやそのプロジェクトの工程によってユースケースをどこまで詳細に記述すべきかが決まる。ユースケースは、あるビジネス目標を達成する際の外部のアクターと対象システムの相互作用を定義する。アクターとはシステムの外にあってシステムとやり取りをするものであり、ユーザーだったり、別のシステムだったりする。ユースケースではシステムを「ブラックボックス」として扱い、システム外から観測できるやり取りを扱う。これは意図的な方針であり、この方針によって要求仕様の記述が簡略化され、その機能がどのように実装されるかという前提(先入観)を排除することができる。ユースケースは以下のように記述されるべきである。ビジネスの目標を達成するためのビジネスタスクを記述する。適切な詳細さで記述される。ソフトウェア開発者が一回のリリースで実装出来る程度の量である。パフォーマンス・エンジニアリングでは、重要なユースケースにはそれに対応した非機能的要求が存在するとされる。ソフトウェア要求仕様[編集]ソフトウェア要求仕様は、開発対象システムの振る舞いを完全に記述したものである。これには、そのソフトウェアとユーザーとのやり取りを全て記述したユースケースも含まれる。ユースケースは機能要求仕様とも呼ばれる。