開発技術 - 12.システム開発技術 - 3.ソフトウェア要件定義 - 4.業務分析や要件定義に用いられる手法

Last Update : April 15 2021 15:47:37

     

業務分析や要件定義で用いられる手法としては、以下のようなものがある。

a. ヒアリング

システムの利用者に対して、実際に聞き取り調査やアンケートなどを行って、利用者の立場の意見を調査すること。
生の声を聞くことができるので、要件定義や業務分析時には有効である。
システム要件をもれなく調査するためには、ヒヤリングの目的・ヒヤリングする対象者・ヒヤリング項目などを明確にし、ヒヤリング計画書を作成する。
実施した場合は、ヒアリング議事録を残しておく。


b. モックアップ・プロトタイプ

最低限の機能を持ったシステム(プロトタイプ)や外観のみ出来上がったシステム(モックアップ)を短期間で作成し、それを取得者に確認してもらい、より具体的なイメージを持って、改善点などを確認する方法。


c. ユースケース図

利用者から見たシステムの振る舞いを記述する。
アクター(棒人間)・・・システムのユーザーやシステムと情報のやり取りをする外部システム
ユースケース・・・アクターと関係付けられるシステムの機能を表す

利用者側の視点に立ってシステムを見たとき、どんな機能があるのかを表現するための記法。
アクターとユースケースから構成され、アクターはシステムにかかわる人やシステムのこと、ユースケースは処理内容を示す。

d. DFD

データの流れに着目して、業務フローを図で表したもの。

  • ・・・データの発生源(ターミネータ)
  • ・・・プロセス(データに加える処理)
  • ・・・データフロー(データの流れ)
  • ・・・データストア(データの蓄積)


e. E-R図

システム化の対象を「エンティティ(実体)」とエンティテイ間の「リレーションシップ(関連)」で分析して、E-Rを記述する。関連には、「1対1」「1対多」「多対多」がある。


f. UML

g. その他の手法

コンテキストダイアグラム
コンテキストダイヤグラム(Context diagram) とは、最上位のDFDであり、情報システムの最終的な入出力である源泉と吸収をひとまとめにして表したものである。 ここではプロセスは1つだけであり、そのプロセスに関連する源泉と吸収の関係だけを検討する。プロセスの詳しい処理を別のDFDとして、定義する。

ミニスペック
最も詳細に記述されたDFDの処理内容を自然言語や擬似言語で表現したもの。

決定表(デシジョンテーブル)
複数の条件の組み合わせによって、とるべき行動を決定するために用いる。
条件とその組み合わせによりどういう行動をとるかを整理した表のこと。

女性YYYN
30歳以下YYNN
既婚者YNNN
リスト1を出力X---
リスト2を出力-X-X
リスト3を出力--X-




     

www.it-shikaku.jp