Software Quality.com

3.4 お知らせのコーナーに"SEC セミナー in 札幌 受付開始”を掲載

ホーム
What's new
お知らせ
サイト マップ
Softwareを取り巻く状況
用語解説
要求工学
利用品質/人間中心設計
ソフトウェア品質特性
プロトタイプ
レビュー
マネジメント
SW構成管理
books
プロセス改善
独り言・私語
training
reference
当サイトについて
お問い合わせ
★HIT Forum
要求工学(Requirement Engneering)
 
ソフトウェアエンジニアリングの中で、要求定義の手順や要求事項を引き出す技法、ノウハウなどを体系化し、整理したものが要求工学です。
その内容はSWEBOKでも章立てに使われるなど業界でも共有化されつつありますのでここでもその内容を紹介しておきます。
プロセス

プロセス要素

概要
要求開発

要求抽出・引出し

ユーザから要求事項を引出す

同上

要求分析引出した要求事項を分析する  

同上

要求仕様作成分析結果をドキュメント(文面・図・表など)にまとめる

同上

要求の妥当性確認要求仕様の内容がシステムの意図や用途に合うのかを確認する
要求管理

 -

プロジェクト全期間で作成した要求仕様の整合、完全性を確保する

<注1>
「要求」とは、”ソフトウェアやシステムを利用することで実現すること、したいこと”を指しています。
その実現のためにソフトウェアやシステムのインターフェース、構造、機能を詳細に落とし込んだものが「仕様」です。
<注2>
要求工学では、これらのプロセスやタスクがシーケンシャルに進行していくのではなく、何度も繰り返しプロセスやタスクを実施しながら進行する、つまり要求の内容が段階的に、あるいは反復的に明確化・成長していくと考えられていることに注意してください。
 
【要求:Requirements】とは?
IEEEによれば、要求とは以下のように定義されています。
1.問題解決または目的達成のためにユーザが必要とする条件や能力
2.契約、標準、仕様、あるいは他の正式文書を遵守するために、システムやシステム構成要素が満足する、または保持しなければならない条件や能力
3.1や2のような条件や能力を文書で表現したもの
 
このほかにも「製品が持つべき特性」「何を実装するべきかの仕様」など、いろいろな定義があるようです。
 
【要求:Requirements】の重要性
言うまでもありませんが、要求事項はソフトウェア開発にとって非常に重要です。
要求事項は、実作業を見積もり、計画するために必要ですのでプロジェクト管理の基盤であると言えます。
また、求めれられるソフトウェアを作り上げる(開発する)ための元となる情報源です。
 
  要求 → (見積・計画立案) → 計画・スケジュール → (作業)
  要求 → (分析・設計) → 仕様 → (実装)→ コード
 
要求事項は、ソフトウェア開発作業のすべての根源だということができますね。
要求事項を不明確、不整合なままにしたり、いい加減に取り扱われると、プロジェクト管理も、作り上げるソフトウェア自体もおかしなことになるのは当然のことです。
とはいえ、要求事項を開発し、管理することは簡単ではありませんし、銀の弾丸(あっという間に解決してくれる魔法のような手段)ももちろんありません。
人間の特性や必要な要求事項の切り口、管理方法を確実に把握した上で対応していきましょう。
 
 
【要求開発】
ソフトウェアによるシステムは規模も大きくなり、用途も多様化しています。そのようなシステムに対して漏れ、誤り、矛盾などがまったくない要求事項を明確にするのは容易なことではありません。
ましてユーザがそのような「完全な要求事項」を整理して提示できるわけはありません。
ですから”要求は開発するもの”という考え方が生まれたのだと思います。
 
<<前提条件>>
要求開発がその効果を上げるためには、顧客・エンドユーザの積極的な協力と協調が必要です。
どんなに要求開発プロセスを実践したとしても、顧客やエンドユーザの協力・協調、自分達が本当に求めるシステムを一緒に作り上げる覚悟と行動なくして、要求開発が成功し、本当に求める(求められる)システムが完成することはないでしょう。
 
1.要求抽出・引き出し
人間は自分が何を求めているのかを完全に理解しているわけではありません。何がしたいのか、何が欲しいのかはユーザに求めても出てこないことも多いですし、それらを矛盾なく、完全な形式で提示することをユーザに求めてもできないことが多いのです。
ですから、(相手から)要求事項を引き出したり、要求事項が存在する場所から抽出したりすることになります。
 
※「相手の立場に立ったコミュニケーション」
コミュニケーションの原則は、単に会話することだけではなく、お互いに同じ認識になること、同じ情報とイメージを共有することです。
そして、システムを使う側の立場で問題領域を見ることが必要です。開発する立場で問題領域を見るだけでは切り口が不足したり、本当の要求事項が出てこない可能性がありますので注意してください。
 
要求抽出・引き出しの主な手段・手法 

■調査(資料収集等)

■インタビュー

■ワークショップ

■ブレインストーミング

■KJ法

■シナリオ

■現場観察

■プロトタイプなど

 
・暗黙の要求事項を明確にする方法1
暗黙の要求事項や曖昧な要求事項を引き出すための有効な手段の一つは(私がよくやるのは)、間違っていても構わないので自分の思い入れを含めた製品イメージを表現・実装し、引き出したい相手に提示してみる方法です。
文字(文章)・図・絵・システムイメージなどで表現することで、相手の頭の中にある曖昧模糊とした要求事項(相手も自分ではよく分かっていない要求事項)とギャップがあれば反応してくれます。
この手法は、お互いの頭の中にあって曖昧なままになっている要求事項や認識を明確化し、相互で理解するために役立ちます。
 
※この原理を使っている手法に「プロトタイピング」があります。
 
・暗黙の要求事項を明確にする方法2
一人だけにインタビューしても出てくる要求事項は断片に限られます。なので複数の関係者に個別インタビューをしたり、一気に集合してもらっていろいろと話してもらうことが有効になります。
そんなことは誰でもわかっていることですが、効果的に選択された複数の対象者に手を抜かずインタビューを実践して構築するソフトウェアに反映している開発者ばかりではない気がします。
 
※この原理を使っている手法に「インタビュー」「ワークショップ」「ブレインストーミング」「KJ法」などがあります。
 
・暗黙の要求事項を明確にする方法3
実務を第三者的に観察すると、様々な問題点が浮かび上がることがあります。
客観的に観察することで「どうしてこの段階でこんなことをしているのかな?」というような疑問が多く出るのです。人間は習慣の動物ですので、意外と自分が普段行っている一つひとつ行動の意味などを理解せずにただなんとなくやっていることが多いのです。
 
※→「現場観察」
 
2.要求分析
抽出した要求事項、引き出した要求事項は不完全、不十分、不整合などの可能性が高いため、要求事項を分析します。
 
分析では解決するべき問題、適用領域、システム要求を明確にします。ここでは「何をしたいのか?」=目的「どんな状況で利用するのか?」=利用状況を中心に明らかにしていきます。
「どのように実現するのか?(実現手段)」を明らかにするのは「設計」で行うことですのでここでは触れません。

★実現手段に踏み込まない理由★
・実現手段に踏み込んだためにそれが制約条件となってさらに効果的な選択肢を検討できなくなる可能性があるため
・実装する手段に目が奪われ、問題の本質を見逃してしまう可能性があるため

対象領域のas-is(現在状態)、to-beあるべき姿 の両面を比較するのが有効です。

 
そして明確化した目的、利用の状況をもとに要求事項を整理していきます。
その際に要求事項としての漏れ、矛盾をなくすために
 

 ■ソフトウェア品質特性

 ■FURPS + (下表参照)

等に基づいて分析するのが有効です。

網羅的な切り口で整理することで、要求事項の漏れ、矛盾を防ぐことができます。

 

FURPS+

 要素内容
機能要求

Functionarity

機能性 

システム機能 
非機能要求

Usabirity

操作性/有用性

使いやすさ、表現の美しさ
非機能要求

Reliability

信頼性

故障頻度、復旧のしやすさ
非機能要求

Performance

性能

処理速度、資源(例:メモリ)使用量
非機能要求

Supportability

保守性・保全性

テスト容易性、拡張性、適応性、保守性
非機能要求

+plus

その他 

 

 

・構造化した図形による分析モデルなど、複数の方法で要求情報を表現する
分析手法:

■DFD

■ER図

■IDEF

■状態遷移図

■データモデリング

■ユースケース

■オブジェクト指向分析  など 

 
<上記以外の要求事項欠落を探す技法>
・特定したすべてのユーザ層から要求を受け取ったかどうかを確認する
・同じ種類の別製品、競合製品を調査し、追加すべき機能はないかを確認する
・仕様が関連するすべての業務ルールに合っていることを確認する
・一定のパターンになる類似の要求を表にまとめて重複や見落としを防ぐ
・製品の一般的機能についてチェックリストを作成する
 準備の時すべての機能のそれぞれに要求が存在していることを確認する
・すべてのデータ項目について、発生源と利用先を記述する
・「したいこと」、と、「ほしいもの」を分ける
人間の思考(考え方)のくせとして”いきなりほしいものを考えてしまう”ということがあります。
たとえば実務の現場で問題が発生したときに、原因をしっかり特定せずに(思いつきの)解決手段ばかりが先に出てくるのもその典型的な事例です。
実際には、したいこととほしいものを混ぜて整理せずに考えている、というのが本質なのかもしれません。
 
「したいこと」とは、目的・意図・解決したい問題そのもの等を指します。また「ほしいもの」とは、対応策・解決手段のことです。
これらをしっかり分けて考えること、そして要求分析では「したいこと」を徹底的に明確化すること+「ほしいもの」を検討から外すことが重要です。
 

 要求分析の対象領域

設計の対象領域 

  したいこと

目的・解決したい問題

 ほしいもの

対応策・問題解決手段

×障子を張り替える

 (これは解決手段)

△破れて見た目が

 悪い障子を何とか

 したい

(利用の状況が不明)

○小さな子供がいる

 新築の家(利用の状況)で、障子をできる

だけきれいな状態

で維持したい

△障子紙を張り替える(でもきっとまた破れる)

 

 

○破れない素材で障子を仕上げる

 
 
3.要求仕様作成
明確化された要求事項を文書化するのが要求仕様の作成です。
要求事項を分析した結果を文書化する、というよりは要求事項を文書化する(または文書化した結果を確認する)ことを通じて要求事項を分析する、というのが現実の姿ではないかと思います。
 
品質評価の前提条件
製品品質(quality)は要求事項全体のうちどの程度が実現できているかを示すのでしたね。
ですから、要求事項が文書化されていない組織は製品品質がどの程度かを評価できないでしょうし、していないと考えて良いでしょう。
どの程度実現できたかは、どのくらいあるのか、どのくらい満足したかが明確に分からないと評価できません。
 
ですから要求事項の文書化は必須だと考えてください。
もしも要求事項の文書化は要らないという方がもしいたら、その方はいい加減な仕事をしている方(それを効率的な開発だと思い込んでいる方)か、または動かなくなってもかまわないようなソフトウェアを個人レベルで楽しんでいる方(あるいは属人化した作業にはまりまくっていて何も手が打てていない方)くらいだと思います。
とはいえ、要求事項を文書化することは目的ではなく手段です。書けばよいというものではないので注意してください。
文書化により粒度も切り口も様々な要求事項を全体として整理し、矛盾・不整合、抜け・漏れ、過剰さ等を解消し、以降の作業に対するベースラインを設定します。
また、メンバー間での情報共有と一元管理も実現します。
 
要求仕様に求められる主な特性(IEEE830より)
①完全性
②正確性
③一貫性
④検証容易性
⑤修正容易性
⑥追跡性・参照容易性

 

4.要求の妥当性確認

妥当性確認(validation)とは、そもそも顧客が持っている「使用」「用途」への要求事項及びニーズに合致していることを確実にするために実施する確認行為のことです。

別の表現で言うと、システムを構築する目的を果たす内容になっているかを確認する行為ということになります。

 

(注)妥当性確認のことを”確証”と訳す方もいらっしゃいます。

 

品質システムや品質マネジメントシステムの要求事項には「設計の妥当性確認」が登場しますが、これは設計案が完成した時点(ソフトウェア開発においては主に最後のテスト工程)でその確認(妥当性確認)を行うことを意図していますが、この時点で行われたとしても、時すでに遅しであることが多いわけです。

ですので、それよりも早い段階である要求定義段階での妥当性確認は非常に重要です。

 

その重点となる確認ポイントは「ユーザビリティ(usability)・人間中心設計」に記載されていますので参考にしてください。

 

確認方法には、シナリオによる確認、レビューによる確認、プロトタイプ(ペーパープロトタイプを含む)による確認など様々な手法が提案されています。

確認時点でもっとも効果的な手段を採用して行ってください。

 

 

【要求管理】

5.要求管理

バージョン管理、変更管理、追跡