ソフトウェア工学１第2回 ソフトウェア・プロセス

要求分析（１）

2017年4月25日中島

1

授業内容

1. ソフトウェアの作業の流れ

2. ソフトウェア・プロセス

プロセスの分類

ライフサイクル・プロセス・モデル

3. 要求分析（１）

要求分析とは

要求分析の難しさ

要求欠陥の分類

2

ソフトウェアの作業の流れ

開発のV字モデル• 左：下向きに分割と詳細化。右：上向きに組立と検証• 左の 要求・設計事項 を、右で 検証 する

システム要求定義・設計

ソフトウェア要求分析

ソフトウェア外部設計

ソフトウェア内部設計

コーディング

ソフトウェア結合テスト

ソフトウェアテスト

システムテスト

ソフトウェア単体テスト

ソフトウェア開発

システム開発

検証詳細化

3

各段階の作業内容：

• デジタル時計を例に

4

８：２０ 設定用ボタンモードボタン

ランプボタン

システム要求定義・設計

機能要求 （～できる）

品質要求（例：使いやすい，性能がよい）

ハードとソフトの機能配分 ＋ ハードの仕様

ハード ⇔ ソフト のインタフェース

８：２０ 設定用ボタンモード

ボタン

ランプボタン

成果物： システム仕様書

ライトをもつ 液晶ディスプレィ（日付と時刻表示用） ボタンは３つ（ランプボタン、設定用ボタン、モードボタン） マイコン (MITSUBISHI MM64K)

5

時刻を24時間単位で設定でき、デジタル表示する。 日付を設定でき、デジタル表示する。 暗いところでも時刻を見ることができる。

簡単な操作（ボタンを押すだけ） わかりやすい表示（モードがあってもユーザにとって理解し易い）

マイコンの, クロック、レジスタなどの仕様 ライト制御、液晶ディスプレィ制御のための信号I/F仕様 ボタン装置入力信号仕様（モード、設定、ランプON、ランプOFF イベント）

ソフトウェア要求分析

機能要求：

ソフトウェア視点からのふるまいとデータ入出力

品質要求

ソフトウェア

外から見るとどうふるまう？

成果物： ソフトウェア要求仕様書 6

モード制御機能： モードボタンで以下の順にモード変更

時刻表示→日付表示→時刻設定（時→分）→日付設定（月→分）→時刻設定

時刻設定機能： 時刻設定モード：設定ボタンで時刻が１アップ。24を越えると0に戻る

日付設定機能、時刻表示機能、日付表示機能：(同様)

ライト制御機能： ランプONでライトが点き、ランプOFFでライトが消える

表示は利用者にとって見易さを損なわないこと（ちらつき、残像なし）

イベントに対して即座に反応すること

保守性に優れたモジュール構造とすること（複雑度＜5以下）

ソフトウェア外部設計

ソフトウェア構成要素（コンポーネント）の定義

外部インタフェースの定義

コンポーネント間のインタフェースの定義

要求を満たす上での基本方式の選択

コンポーネントソフトウェア

基本方式

成果物： ソフトウェア外部設計書 7

入力信号処理プログラム

論理処理プログラム

ライト制御プログラム

液晶ディスプレィ制御プログラム

イベント入力と制御信号出力

それらのタイミングとシーケンス

割り込み処理方式

メモリ利用

ソフトウェア内部設計

• 各コンポーネントを、プログラムモジュールへ分解

• プログラムモジュールの仕様を記述

ソフトウェア

コンポーネント

プログラムモジュール群

成果物： ソフトウェア内部仕様書 8

論理処理プログラム

モード管理モジュール： modeManage引数：

e 入力 型：intact 出力 型：intmode 入出力 型：int (値範囲:1～12)

機能仕様： eがX⇒対応するactとnmodeを返す例外処理： eがYのとき、エラーを返す戻り値： なし

時刻設定モジュール

日付設定モジュール

表示制御モジュール

入力信号処理プログラム…

コーディング

• プログラム設計 （PAD）

• コード作成

• コードレビュー

やっとプログラム登場！

成果物： PAD、 コード 9

void modeManage(int e, int& act, int& nmode){

if (mode == WW) && e == XX) {

act = YY;nmode =ZZ;

}…

}

ちょっと考えてみよう１

• 企業のソフトウェア開発では， 「ソフトウェア作業の流れ」に沿って開発を進めることが多い．つまり

– 指定された作業の実施

– 中間成果物の作成

にまとめながら開発は進む．

• そうしないと，開発でどんな問題が起きると思うか？（想定：作る人と使う人は違う，チームで開発する）

• 個人で3分，席の前後隣りで3分

10

ソフトウェア単体テスト

• ソフトウェア内部設計と対応したテスト

– プログラムモジュール単体 を実行して確かめる

void modeManage(int e, int& act, int& nmode){

if (mode == WW) && e == XX) { act = YY; nmode =ZZ;

}…

}

ソフトウェア内部設計書

入力照合

出力

OK／NG

テストケース

テストの実行

成果物： ソフトウェア単体テスト仕様書／成績書 11

ソフトウェア単体テスト仕様書

入力 出力期待値act = YY &&nmode = ZZ

mode = WW &&e = XX

プログラム

ソフトウェア結合テスト

ソフトウェア外部設計に対応したテスト

– 各コンポーネントが仕様通りかを確かめる

– コンポーネントを結合して、その外部インタフェースと内部インタフェースが仕様通りか確かめる

– 基本方式 が意図した性能を達成できるかを確かめる

コンポーネントソフトウェア

基本方式

外部インタフェース

内部インタフェース

成果物： ソフトウェア結合テスト仕様書／成績書 12

入力信号処理プログラム+ 論理処理プログラム

…

割り込み処理方式の有効性メモリ利用の効率性

最終テスト

ソフトウェアテスト（←ソフトウェア要求分析に対応）

– ソフトウェアがソフトウェア要求仕様通りかどうかを確認

– （実機やテスト用ハードを利用する場合、シミュレーションで行う場合がある）

システムテスト（←システム要求定義・設計に対応）

– ソフトとハードを組合せてそのインタフェースを確認

– 「製品」の状態でシステム要求通りかどうかを確認

８：２０

成果物： システムテスト仕様書／成績書

成果物： ソフトウェアテスト仕様書／成績書

13

ちょっと考えてみよう２

• なぜ、単体テスト、結合テスト、ソフトウェアテストのように段階を分けているのでしょうか？

• P3 の図をみて考えよう。

• 個人で2分，席の隣りで3分

14

授業内容

1. ソフトウェアの作業の流れ

2. ソフトウェア・プロセス

プロセスの分類

ライフサイクル・プロセス・モデル

3. 要求分析（１）

要求分析とは

要求分析の難しさ

要求欠陥の分類

15

ソフトウエア・プロセスとは

• ソフトウェア・プロセス＝開発工程や手順の定義ステップ＋入出力生産物＋作業内容

• 何に使うか？

– プロジェクトの制御（開発進捗、製品品質）

– 標準化→ コミュニケーションの円滑化（組織内＋外注）

ノウハウの蓄積とやり方の改善

教育の容易化

16

ソフトウェア・プロセスとは

粒度

技術依存性

小 大

小

大

ﾗｲﾌｻｲｸﾙ･ﾌﾟﾛｾｽ・ﾓﾃﾞﾙプロジェクトマネジメント

思考方法の再利用

作業標準化

・ｳｫｰﾀ･ﾌｫｰﾙﾓﾃﾞﾙ・ｽﾊﾟｲﾗﾙﾓﾃﾞﾙ

分析・設計手法・オブジェクト指向手法・構造化分析・設計手法

(記述方式と利用ツール）

開発規則・開発工程・文書体系

プロセス（定義）の分類

17

ちょっと考えてみよう3

要求 完成品

ソフトウェア開発

• 信用度の低いソフトウェア外注に、「要求」を出して、完成品が出てくるまで、何も口を出さないでいると何が起きそうか？

• リスクと思われることを3つあげよ。• 個人で3分

18

ライフサイクル・プロセス・モデル

システム開発を管理するためのプロセスのモデル

• 目的： プロジェクトの制御

• 記述： 複数の開発工程（フェーズ）への分解と工程間の関連を定義

• 特徴： 汎用性が極めて高い

要求 製品

ソフトウェア開発

製品

ﾏｲﾙｽﾄｰﾝ ﾏｲﾙｽﾄｰﾝ

例： ウォータフォール、スパイラル、インクリメンタル、アジャイル・・・ 19

マイルストーン （一里塚）

• 物事の進捗を管理するために途中で設ける節目

20

ゴール

要求分析

外部設計

内部設計

システムテスト

結合テスト

単体テスト

コーディング

例1： ウォータ･フォールモデル

ソフトウェア製品の本来的性質により破綻

①最後まで何を作ったらよいか分からない

②重要な品質（信頼性、性能、使用性など）は動くようになってやっと判断できる

W. Royce

要求分析

設計

構築

テスト

運用・保守

一連の段階的工程からなり、成果物作成の進捗と品質を監視することで、プロジェクトを制御する

手戻り

欠点： 各工程での誤りがとれにくい

→不具合発見がテスト段階以降に集中

ソフトウェア要求仕様書

ソフトウェア設計書

コード

テスト済コードテスト成績書

21

不具合

例2： スパイラル・モデル

目的、対案、制約の決定

ﾘｽｸ分析

ﾘｽｸ分析

ﾘｽｸ分析

ﾘｽｸ分析

ﾌﾟﾛﾄﾀｲﾌﾟ1ﾌﾟﾛﾄﾀｲﾌﾟ2

ﾌﾟﾛﾄﾀｲﾌﾟ3

ﾊﾟｲﾛｯﾄｼｽﾃﾑ

対案の評価ﾘｽｸの識別と解決

統合とﾃｽﾄ計画

次のフェーズの計画

要求計画

ﾗｲﾌｻｲｸﾙ計画

開発計画

レビュー ｼﾐｭﾚｰｼｮﾝ・ﾓﾃﾞﾙ・ﾍﾞﾝﾁﾏｰｸ運用の概念

次のレベルの生産物の開発・検証

詳細設計

ｺｰﾃﾞｨﾝｸﾞ単体ﾃｽﾄ統合

ﾃｽﾄ受入ﾃｽﾄ

実装

S/W要求

要求検証

S/W製品設計

設計検証

B. Boehm

• プロジェクトを阻害する大きなリスクを、早期にコスト小さく解決• 複数回の開発サイクルを回す。最後のサイクルが製品開発

22

授業内容

1. ソフトウェアの作業の流れ

2. ソフトウェア・プロセス

プロセスの分類

ライフサイクル・プロセス・モデル

3. 要求分析（１）

要求分析とは

要求分析の難しさ

要求欠陥の分類

23

要求分析とは

ソフトウェア設計者

「よくわかりました。さっそくとりかかります。」

要求仕様書

顧客

要求分析者

「あれができたらな」

要求分析顧客ニーズ

顧客ニーズを要求仕様(書）にまとめる過程

24

要求分析とは：視点

• 要求分析者は、顧客と開発者の２つの視点に立ち、品質とコストと納期をバランスさせなければならない

顧客の視点 開発者の視点

• ニーズ：目的・目標• 業務プロセス• 制約条件（ビジネス

ルール、運用環境）

• 明確な機能と品質要求• 技術／コスト的実現性• テスト容易性

要求分析者

品質 コスト納期

25

要求分析の難しさ

• 要求変更は悪！– 仕様修正コストは、後工程で雪ダルマ式に増大

仕様誤り修正コスト

（5倍）

（10倍）

（20倍）

（200倍）

要求分析

設計

ｺｰﾃﾞｲﾝｸﾞ

テスト

運用開始

26

要求分析の難しさ

• しかし、要求変更は必ず起きる

②要求者の要求自体が あいまい

①ステークホルダに コンセンサス なし

③ｺﾐｭﾆｹｰｼｮﾝが不完全

④要求記述が低品質

要求仕様書

顧客

要求分析者

ユーザ要求

⑤ 環境の変化〔ビジネス、運用〕

システム

発注元，経営者，ユーザ，オペレータ，保守者・・・

27

要求分析の難しさ：実例

契約１ 契約2

28

要求分析の難しさ：実例

初期コストと同じ

仕様変更

要求分析

29

要求モデル要求仕様

要求分析のプロセス

• 顧客とのやりとりを中心に獲得→分析・仕様化→妥当性確認の繰り返し

• 要求仕様・モデルを利用

要求の獲得作業

分析・仕様化

獲得 妥当性確認

要求の確認作業

顧客現場調査ｲﾝﾀﾋﾞｭｰ 要求書ﾚﾋﾞｭｰ

ﾌﾟﾛﾄﾀｲﾌﾟﾃﾞﾓ

あいまいさ、誤り，抜けへの挑戦！

30

（参考）要求分析の知識体系

[SWEBOK]SoftWare Engineering Body

Of Knowledge

「ソフトウェア要求」の知識領域とトピックス

ソフトウェア要求

要求工学プロセス

要求の獲得 要求分析 要求仕様要求の

妥当性確認要求管理

６つの知識領域

・プロセスモデル

・プロセスアクタ（ステークホルダ）

・プロセス支援及びマネジメント

・プロセス品質と改善

・要求の生成源

・抽出の方法

・要求クラス分け

・概念モデル作り

・アーキテクチャ設計及び要求割付

・要求折衝

・要求定義文書

・ソフトウェア要求仕様(SRS)

・文書構造及び標準

・文書の品質

・要求レビューの実施

・プロトタイピング

・モデルの妥当性確認

・受け入れテスト

・変更管理

・要求属性

・要求確認

31

分析： 欠陥の分類

• 要求にはどんな欠陥があるのか

– 誤り： そもそも顧客が望んでいない

– 抜け： 顧客が暗黙に必要／必然的に必要なのに抜けている

– 矛盾： 仕様同士、運用環境、ﾋﾞｼﾞﾈｽﾙｰﾙと整合していない

– あいまい： いろいろな意味に解釈できる

– 検証不可能： 実現したかどうか確かめる手段がない

– 実現不可能： 技術的／コスト的に実現できない

32

クイズ

次の仕様で何が問題と思いますか？前ページの分類で答えよ。

1. システムＡから送信される制御データ(2ﾋﾞｯﾄ)による制御動作の仕様：• 制御データ２のとき、制御動作ＡをON• 制御データ１のとき、制御動作ＢをON• 制御データ０のとき、制御動作をOFF

2. システムは、操縦モードＡのとき、あらゆる条件下で機体を水平に保つ

べく機体を制御する。

3. システムは、月まで１秒で到達しなければならない。

4. システムは、ユーザフレンドリでなければならない。

5. システムは、あらゆる侵入者よりシステムをまもらなければならない。

6. 電子音の仕様

• システムはアラーム設定ができ時間がくると電子音を鳴らす。

• システムはマナーモードのとき電子音を鳴らさない。

33

今日のまとめ

• ソフトウェア開発は、プログラミングだけじゃない。

• V字モデル： 設計と検証、分割と組立

• プロセス＝開発工程や手順の定義ステップ＋入出力生産物＋作業内容

• 要求分析

– 繰り返し： 獲得→仕様化・分析→妥当性確認

– 要求分析の難しさ： 要求変更は必ず起きる

– 要求欠陥の分類誤り,抜け,矛盾,あいまい,検証不可能,実現不可能

34