講義用ノート(4コマ目)
27
0
0
全文
(2) Copyright©2013 IPA All Right Reserved. 2.
(3) Copyright©2013 IPA All Right Reserved. 3.
(4) Copyright©2013 IPA All Right Reserved. 4.
(5) Copyright©2013 IPA All Right Reserved. 5.
(6) Copyright©2013 IPA All Right Reserved. 6.
(7) 【解説のポイント】 企業や組織にとってゴールと現状には必ずギャップがあります。 そのギャップを埋めるための手段(条件や能力)が“要求”となります。 【解説のガイド】 企業や組織にとって、ゴールを立てた場合、現状と比べてギャップが生じます。 そのギャップを埋めるということが解決すべき課題となります。 その課題を解決するにあたっての条件、能力、つまり何をすればギャップが埋まるのか。それが要求となり ます。. Copyright©2013 IPA All Right Reserved. 7.
(8) 【解説のポイント】 顧客が認識している要求は氷山の一角です。 顧客自身、認識していなかった要求が隠れていることが多くあります。 ベンダがそれらを導き出すことが重要となります。 【解説のガイド】 ①は文書化されているような要求となります ②は顧客も当然必要と思っている要求のため、すぐに抽出が可能となります。 ③は顧客自身気付いていないため、ベンダが気付いてもらうことが重要です。. Copyright©2013 IPA All Right Reserved. 8.
(9) 【解説のポイント】 要求は4種類あり、それらをきちんと抽出して関係者間で共通理解するために文書化する必要があります。 重要なことは、特に認識されていない要求を引き出して文書化することです。 そのためには、聞き手が仮説を持ってヒアリングするなどのスキルが求められます。 【解説のガイド】 4種類の要求の内、表明されている要求はすでに明文化されていることもあり、容易に抽出することがで きます。 表明されていない要求、示唆された要求は、ヒアリングなどから抽出する必要があります。 それは、顧客数名にヒアリングすると共通して発言されることが多いことや、ヒアリング内で補足されること が多いためです。 一方で、最後の認識されていない要求は顧客が認識していない要求のために単純にヒアリングしても抽 出はできません。 そのため、聞き手はある程度の顧客が抱えているであろう課題の仮説をもってヒアリングする必要があり ます。 そうした結果、顧客が課題について認識し要求を引き出すことができます。 大切なことは、表明された要求だけではなく、如何にして示唆された要求、認識されていない要求を引き 出すかということです。. Copyright©2013 IPA All Right Reserved. 9.
(10) 【解説のポイント】 システムの概念は、情報システムのみを指すわけではありません。 システムとは人や組織、情報システム(ハードウェア、ソフトウェアなど)を含めた仕組みのことを指します。 【解説のガイド】 例ではDVDレンタル店舗の仕組みを取り上げています。 顧客や店舗もシステムの一部であり、商品管理、会員管理などの情報システムも 当然システムの一部となります。. Copyright©2013 IPA All Right Reserved. 10.
(11) 【解説のポイント】 要求を捉える視点は一般的に3つに分類されます 構造の視点:システム要素の関連性の視点 機能の視点:機能(=働き)の視点 振舞い(挙動):状態遷移の視点 【解説のガイド】 構造の視点は、システム要素の関連性に着目します。銀行システムを例にとると、銀行には銀行員の利用 する業務用端末、 窓口に設置する窓口端末、利用者の使うATMなどがあり、それぞれの関連性の視点から、要求を理解し ます。 機能視点は、入力データに対して、機能(働き)があり、何を出力するかの視点で要求を理解します。 例えば、ATMでは、キャッシュカードと暗証番号が入力情報となり、個人認証が機能(処理)となります。 出力はお金を引き出す、または暗証番号間違いによるNGなどになります。 振舞いの視点は、状態遷移に着目して要求を理解します。 例として、銀行の順番待ちを管理するシステムを考えます。 順番待ちが全くない場合には「受付中」とし、受付待ちが入ったら、「受付待ち」といったことになります。 こういった状態変化の視点から、要求を捉えます。. Copyright©2013 IPA All Right Reserved. 11.
(12) 【解説のポイント】 要求は色々な特性を持っているために、すべてをもれなく把握しようとすると、 複数の視点から捉えることが重要となります。 例は、前ページの例をそれぞれイメージしたものになります。 【解説のガイド】 構造の視点の例は、業務用端末に対して、窓口端末とATMがどのように関連しているかを見ています。 機能の視点では、顧客認証といった機能(=処理)が行われていることを示しています。 振舞いの視点では、受付によって、「受付中」から「受付待ち」に状態が変化していることを示します。. Copyright©2013 IPA All Right Reserved. 12.
(13) 【解説のポイント】 上述した通り、要求は多様で複雑です。そのため、要求を性質や範囲に応じて3つに分類します。 3つとは、ビジネス、情報システム、ソフトウェアとなっています。 これら3つに分類された要求は、それぞれの整合を図っていくことが重要となります。 【解説のガイド】 要求のスコープとは、要求の範囲を整理するということです。 ビジネス要求は、経営層など企業や組織がビジネスを遂行していく上で目指すための要求となります。 情報システムの要求は、ハードウェアとソフトウェアを合わせた要求となっています。 ここで言うハードウェアとは、PC端末やネットワーク機器などを指します。 ソフトウェア要求とは、ハードウェアを動かすためのプログラムもしくはハードウェア上で動くプログラムの ことです。 例えば、携帯電話はハードウェアであり、アプリケーションはソフトウェアとなります。 ソフトウェア要求は、情報システム要求からハードウェア部分を除いた要求となります。. Copyright©2013 IPA All Right Reserved. 13.
(14) 【解説のポイント】 ビジネス要求は、企業・組織における戦略、ゴールを達成するために必要な要求です。 これらは要求を実現できたかどうかを検証する必要があるために具体的数値を取り入れた要求が好ましく なります。 【解説のガイド】 システム開発のスタートは、ビジネス要求を抽出するところから始まります。 その際には、どのような視点で要求を抽出するかを考えます。視点のもれが無いように留意します。 要求を抽出し、定義する際には、検証可能な要求(定量化など)として定義することが好ましくなります。 ただし、全ての要求が検証可能な状態で定義できるとは限りません。 顧客に対してヒアリングして、要求を抽出する際の視点の例は 顧客満足度、売上、コスト、ブランド力、運用などがあります。. Copyright©2013 IPA All Right Reserved. 14.
(15) 【解説のポイント】 情報システム要求は、ソフトウェアのみならず、ハードウェアを含む要求のことを指します。 この要求は上位のビジネス要求を満たすためにどのような情報システム(ハードウェア、ソフトウェア)が 必要になってくるかを定義します。 こちらもビジネス要求同様に、具体的な数値を取り入れて定義することが好ましくなります。 【解説のガイド】 情報システムの要求として、3つの例を挙げます。 1.初心者が4時間の研修で事務処理を1時間に10件処理できる画面 これはソフトウェア(携帯のアプリと同じようなもの)要求であり画面がわかりやすく、 半日の研修で事務処理を行えるようなものにするという要求です。 2.生産計画立案の処理を検証含めて2時間で終える処理性能 これはソフトウェア要求であり、ソフトウェアの性能面の要求です。 3.必要なハードディスクは、メモリ8GB、容量は400GB以上 これはハードウェア(PCのようなもの)の要求です。 4.障害発生後、2時間以内で復旧 これは、情報システムの運用に関する要求です。. Copyright©2013 IPA All Right Reserved. 15.
(16) 【解説のポイント】 情報システム要求の内、ハードウェア面の要求を取り除いた要求のことをソフトウェア要求を言います。 【解説のガイド】 情報システム要求を実現する方法として、ハードウェア要求とソフトウェア要求があります。 ソフトウェア要求とは、情報システム要求に包含された要求を指します。 主な要求は、機能要求、性能要求、セキュリティ要求、運用要求などが挙げられます。. Copyright©2013 IPA All Right Reserved. 16.
(17) 【解説のポイント】 システムは、長期にわたって適切に運用され続ける必要があります。 そのため、運用に関する要求定義は非常に重要です。 【解説ガイド】 運用要求は、継続的にシステムを利用していく上で非常に重要な要求となります。 運用要求は、ビジネス要求、情報システム要求、ソフトウェア要求のそれぞれに含まれており、それぞれの 要求を検討する際に、運用について検討しなければなりません。 運用要求の例: ビジネス要求:サービス利用時間は平日8:00〜25:00とする 情報システム要求:障害発生後、2時間以内で復旧する ソフトウェア要求:セキュリティパッチは自動で適用する. Copyright©2013 IPA All Right Reserved. 17.
(18) 【解説のポイント】 要求は、顧客とベンダの間で調整し、最終的に要求仕様書となります。両者の間で要求を構造化や有用 性の確認していき、共通理解となるようにまとめていくことが重要となります。 【解説のガイド】 要求は、経営層やシステム利用者(エンドユーザ)の要求に落とし込まれ、ベンダとの共通理解のもと、4 階層に分類されていきます。 それらの要求をシステム開発するベンダはもれなく抽出していきます。 そして、分析、構造化、文書介していく中で要求を具体化し、顧客、ベンダが共通理解できるように品質を 高めていきます。. Copyright©2013 IPA All Right Reserved. 18.
(19) 【解説のポイント】 要求は機能面から2つに分類することができます。 それぞれ、機能要求と非機能要求となります。 【解説のガイド】 要求を機能の側面から見ると、機能要求と非機能要求に大別されます。 機能要求は本来果たすべき機能となります。つまり、「何をしなければならないのか?」に対する答えです。 例えば銀行システムで、「振り込みができること」といった、システム利用者の要求がベースとなる機能で す。 非機能要求は、機能要求以外を指します。システムの応答時間や障害発生時の復旧時間などとなります。 例えば銀行システムで、「顧客認証は2秒以内に処理すること」、「ネットバンキングは24時間稼働してい ること」といった、 ソフトウェアに求められる処理スピードや稼働率などの機能です。 非機能要求はもれなく抽出することが困難だと言われている一方で、ビジネス面から見ると 非常に重要な要求となるため、慎重に検討を進める必要があります。. Copyright©2013 IPA All Right Reserved. 19.
(20) 【解説のポイント】 機能要求はシステムに必要な働きとなります。 【解説のガイド】 例は宅配ピザにおける求められる働きとなります。 顧客は受付(店舗)に電話します。受付は顧客検索や新規顧客であればその旨を登録します。 また、ピザの注文を受け付けて登録します。 調理係は注文が登録されると、調理開始の通知を受け取ります。 そして、調理開始⇒調理完了などのステータスを登録します。 ドライバーは調理完了の通知を受けると、配達します。 その際、配送ステータスに配送中⇒配送完了を登録します。. Copyright©2013 IPA All Right Reserved. 20.
(21) 【解説のポイント】 非機能要求は、機能要求に比べて把握が難しいため、ユーザが漠然と思い描いている内容が多くもれな く抽出することは難しい。 【解説のガイド】 非機能要求は、顧客にとって必ず実現したい業務に比べると関心が低くなりがちです。その上、システム 的な要素が強く専門知識が必要ともされるため、具体的にどのような要求を出せばよいのか難しいのも現 実です。 「十分早く」、「しっかり対策をとって欲しい」といったような形での要求となってしまいがちです。 そこで、具体的、できれば定量的な要求の内容にします。. Copyright©2013 IPA All Right Reserved. 21.
(22) 【解説のポイント】 非機能要求とは、ソフトウェアによって果たされる特定の機能とは直接関係しない要求のことです。 そのためか、見落とされがちになるものでもあります。 見落としがないように、複数の視点から要求を抽出するアプローチが重要となります。 【解説のガイド】 非機能要求は本来機能を果たす上で付加価値的な要素とみられています。 そのため、見落とされがちですので複数視点からもれなくしていきます。 品質要求の例は、画面から顧客リストを検索した場合に検索結果を3秒以内に表示させる などといった内容になります。 機能要求では「顧客リストを検索できること」に対して、「具体的な応答時間を設けること」が非機能要求と なります。. Copyright©2013 IPA All Right Reserved. 22.
(23) 【解説のポイント】 品質要求は国際基準としてISO/IEC9126とその後継であるISO/IEC25000シリーズがあります。 ISO/IEC25000シリーズで定められている品質要求の特性は3種類になります。 【解説のガイド】 利用品質は、ユーザがソフトウェアや情報システムを利用する際の品質を表します。 プロダクト品質は、ISO/IEC9126シリーズの外部品質(外部に現れる品質)と 内部品質(開発に関する品質)をまとめてプロダクト品質としています。 システム実行する際に外部に現れる品質と内部(開発)に関する品質です。 データ品質は、ユーザがシステムを利用する際、要求を満たすデータとして表現される品質です。. Copyright©2013 IPA All Right Reserved. 23.
(24) 【解説のポイント】 ISO/IEC25000シリーズで定められている利用品質のうち、主なものを紹介します。 【解説のガイド】 利用品質は、ユーザがソフトウェアや情報システムを利用する際の品質を表します。 有効性とは、ゴールを達成する正確さと完全性です。 効率性とは、ゴールを達成するために必要な時間や資源、コストのことです。 満足性とは、有用性や信用、楽しさ、快適さなど、要求を達成する度合いのことです。 リスク緩和とは、経済性や健康、安全、環境など、システムがリスクを緩和できる度合いのことです。. Copyright©2013 IPA All Right Reserved. 24.
(25) 【解説のポイント】 ISO/IEC25000シリーズで定められているプロダクト品質を紹介します。 【解説のガイド】 機能適合性とは、システムが持つ機能が要求を満たしていることを表します。 性能効率とは、処理が想定時間内に完了し、リソースが足りることです。 互換性とは、他のシステムやソフトウェアと共存でき、互換性があることです。 ユーザビリティとは、分かり易く覚えやすく、使いやすく、美しい操作性を備えることです。 信頼性とは、システムが止まらず、止まっても回復しやすいことです。 セキュリティとは、正しい利用者だけが利用でき、矛盾しないことです。 保守性とは、システムの内容が分かり易く、修正しやすいことです。 移植性とは、システムを導入しやすく、置換しやすいことです。. Copyright©2013 IPA All Right Reserved. 25.
(26) Copyright©2013 IPA All Right Reserved. 26.
(27) Copyright©2013 IPA All Right Reserved.
(28)
関連したドキュメント
そこで本解説では,X線CT画像から患者別に骨の有限 要素モデルを作成することが可能な,画像処理と力学解析 の統合ソフトウェアである
うのも、それは現物を直接に示すことによってしか説明できないタイプの概念である上に、その現物というのが、
心臓核医学に心機能に関する標準はすべての機能検査の基礎となる重要な観
仏像に対する知識は、これまでの学校教育では必
攻撃者は安定して攻撃を成功させるためにメモリ空間 の固定領域に配置された ROPgadget コードを用いようとす る.2.4 節で示した ASLR が機能している場合は困難とな
に関して言 えば, は つのリー群の組 によって等質空間として表すこと はできないが, つのリー群の組 を用いればクリフォード・クラ イン形
これらの定義でも分かるように, Impairment に関しては解剖学的または生理学的な異常 としてほぼ続一されているが, disability と
口腔の持つ,種々の働き ( 機能)が障害された場 合,これらの働きがより健全に機能するよう手当