ソフトウェア工学１第3回 要求分析（2）

2017年5月1日

中島

1

授業内容

• おさらい

• 要求とは

– 要求仕様書

– 要求の種別

• 仕様化・分析

– 機能要求

– 品質要求（非機能要求）

2

ソフトウェア開発における要求分析（おさらい）

システム要求定義・設計

ソフトウェア要求分析

ソフトウェア外部設計

ソフトウェア内部設計

コーディング

ソフトウェア結合テスト

ソフトウェアテスト

システムテスト

ソフトウェア単体テスト

ソフトウェア開発

システム開発

3

要求分析の難しさ（おさらい）

• 要求変更は必ず起きる

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

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

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

④要求記述が低品質

要求仕様書

顧客

要求分析者

ユーザ要求

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

システム

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

4

分析： 欠陥の分類（おさらい）

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

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

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

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

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

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

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

5

要求仕様（要求モデル）

要求分析のプロセス（おさらい）

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

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

要求の獲得作業

分析・仕様化

獲得 妥当性確認

要求の確認作業

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

ﾌﾟﾛﾄﾀｲﾌﾟﾃﾞﾓ

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

利用 利用

6

授業内容

• おさらい

• 要求とは

– 要求仕様書

– 要求の種別

• 仕様化・分析

– 機能要求

– 品質要求（非機能要求）

7

要求仕様書 （ISO/IEC/IEEE 29148)章 節

1. はじめに 1.1 目的1.2 範囲1.3 製品概要

1.3.1 製品展望1.3.2 製品機能1.3.3 ユーザ特性1.3.4 制約事項

1.4 用語の定義

2. 参考文献

3. 要求事項詳細 3.1 外部インタフェース3.2 機能3.3 操作性要求3.4 性能要求3.5 論理データベース要求3.6 設計制約3.7 ソフトウェアシステム属性3.8 支援情報

4. 検証

5. 付録 5.1 前提条件と依存関係5.2 略語の定義

システム要求

8

要求の種別

要求として記述するものは

① 機能要求： システムは何をするのか

② 品質要求： システムの品質はどうあってほしいのか

③ 外部ｲﾝﾀﾌｪｰｽ： 他のシステムとのつながりはあるか

④ 制約事項： 実装に影響を与える決定事項は何か

9

要求の種別： システム要求

カテゴリ 定義 例圧力が 40psiを超えたら、警告灯を点灯する

新しいアイデアが登録されると、システムはコーディネータに電子メールを送信する

保守し易い、信頼できる、使い易い、効率的な

コマンドに対する応答が3秒以内，初心者でも操作ができる

(装置)からシグナルを読まなければならない

(外部システム)にメッセージを送らなければならない(フォーマット)でファイルを読まなければならない

指定するUIFガイドラインに適合していなければならない提出電子ファイルは１０MBの大きさを超えてはならない

制約事項 開発者が利用できる選択肢を正当に制限する記述

外部インタフェース

システムと他のドメイン間の接続を記述

機能要求（～する）

品質要求(-ility)

システムが、ある種の条件下で示す観測可能なふるまいや処理の記述

システムが、何らかのふるまいをどの程度よく実行するかを示す記述

10

要求についてちょっと考えよう

酒類の通信販売を行うE-commerceサイト

① 機能要求： どんなことができたらよいか

② 品質要求： どんな品質を要求したいか（信頼できる、使い易い、効率的な）

③ 外部ｲﾝﾀﾌｪｰｽ：つながる他のシステムはあるか

④ 制約事項： 作り方に制約はあるか（法律，規約，使用言語，使用する

ネットワークやデータベース，・・・）

11

授業内容

• おさらい

• 要求とは

– 要求仕様書

– 要求の種別

• 仕様化・分析

– 機能要求

– 品質要求（非機能要求）

12

なぜ要求モデルを使う？

• 形式性： あいまいさ、矛盾、抜けなく書く、できたら検証も

• 視覚性： 図でユーザとコミュニケーション

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

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

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

④要求記述が低品質

要求仕様書

顧客

要求分析者

ユーザ要求

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

システム

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

13

分析・仕様化： 要求モデル

システム要求

① 機能要求：

② 品質要求：

③ 外部ｲﾝﾀﾌｪｰｽ：

④ 制約事項：

サービス中心： ユースケース

機能中心： データフロー図データ中心： ＥＲ図ふるまい中心： 状態遷移図

14

機能要求を表現する： サービス中心

ユースケース

– システムが提供するサービス、それを使った業務の流れを，

アクタとシステムとのやり取りとして，記述する

– アクタ： システムのまわりの登場人物（他システムも含む）

ユースケース

アクタ

ユースケース図

ユースケース名：

概要：アクタ： 誰がシステムに動き出すきっかけを与えるか前提条件： このユースケースが起動される条件記述： この業務のメインの流れを，システムとのやり

とりとして記述例外処理： この業務の流れ事後条件： このユースケースが終了したときの条件

ユースケース記述15

ユースケースの例： 学会受付システム

受付

参加者

ユースケース名： 受付

概要： 会場で参加者を受け付けるアクタ： 参加者事前条件： シンポジウム当日であること記述：1. 申し込み既登録者かどうかを尋ねる2. 申し込み既登録者の場合、登録者台帳に記載

の氏名、所属を確認して、該当すればシンポジウム資料を渡して、受け付けを完了する

3. 申し込未登録者の場合、当日参加者台帳に氏名、所属、連絡先を記入する

4. つぎに参加費を支払ってもらう。参加費は会員、一般、学生の種類毎に、3000円、5000円、2000円を徴収する

5. 参加費を徴収した後、シンポジウム資料を渡して、受け付けを完了する

例外処理：事前条件： シンポジウム当日であること

事前申込み受付担当

ユースケース図 ユースケース記述

16

ユースケース書いてみよう

銀行ＡＴＭ– ユースケース図

• どんな登場人物がいる（他システムも含む）？

• どんなサービスがある？

– ユースケース記述： 「預金」を考える

• 誰の何からスタート？

• 時間順にユーザとシステムはどうやり取りする？

17

機能要求を表現する： 機能中心

データフロー図 （DFD)– 要求機能を明確にする（入出力の明確化）

– 外部エンティティを明確にする

– 機能を分解する

機能

データフロー

データストア（データを蓄積する場所）外部エンティティ（データの発生源と出力先）

データ名

プロセス名 ﾃﾞｰﾀｽﾄｱ名

ｴﾝﾃｨﾃｨ名

ｴﾝﾃｨﾃｨ： 実体をもつもの18

データフロー図の例： 学会受付システム

参加者 参加者受付

登録者情報

参加費

資料、領収書

参加者

新規登録受付

新規登録

参加費徴収

参加者

登録者台帳

登録済受付

受付完了 資料、

領収書

参加費

参加費

登録者情報

登録者情報

登録者情報

19

データフロー図を書いてみよう

銀行ＡＴＭ– ユースケースと１つ取り挙げよう

– そのユースケースは，どんな機能からなる？

– どんなデータの入出力があるのか？

– どんなデータベースがある？

– その機能はどんな機能に分解できる？

20

機能要求を表現する： データ中心

ＥＲ（Entity-Relationship)図

– 問題領域のデータを把握する

– データ構造を記述する

エンティティ（実世界との対応関係をもつもの）

ｴﾝﾃｨﾃｨ名

属性名 属性（ｴﾝﾃｨﾃｨがもつデータ）

関係名

１個以上の対応関係

１個の対応関係

関係（ｴﾝﾃｨﾃｨ間の関係）

21

ER図の例： 学会受付システム

シンポジウム参加者

受付担当

受付ける

種類 所属

シンポジウム名

シンポジウム番号

氏名

氏名

参加する

22

ER図を書いてみよう

銀行ATM： 銀行口座と利用者① 銀行口座はどんなデータからなる？

② 利用者（顧客）情報とはなにからなる？

③ 銀行 と 利用者の関係は？

23

ヒント• エンティティ： 銀行口座， 利用者• 属性： それぞれの属性 ①②• 関係： ③

親

機能要求を表現する： ふるまい中心

状態遷移図

– システムのふるまいを記述する

「〇〇状態で･･･が起きたら ～をして△△状態に移る」

– システムの状態を明らかにする

状態名状態（ﾓｰﾄﾞ、制御状態、表示状態）

状態遷移（状態間の移動）

ｲﾍﾞﾝﾄ名[条件]/ｱｸｼｮﾝ名

初期状態

子 状態の階層化

状態の並列化タイムアウト（X秒たったら遷移する）

after(x 秒)

24

ふるまいの記述： 状態遷移図

例） 学会受付システム

未受付

未入金

受付済

入金済

登録済

未登録

入金

ｷｬﾝｾﾙ[未受付]

ｷｬﾝｾﾙ[未受付]/返金

受付[登録済]受付状態

登録状態

参加者

25

状態遷移図を書いてみよう

ストップウォッチ LB RB

LB： 計測開始/停止RB： クリア（停止時）/ラップ（計測時）

26

課題

• 学籍番号が奇数の人は問題１，偶数の人は問題2（間違うと採点しません）

• レポートには，氏名，学籍番号，問題番号を書くこと

• 5/9(火） 13:00までに研究棟14G32ポストに提出（または5/9授業に持ってくること）

27

問題1（奇数）： 次の状態遷移図を書きなさい

• 時間設定中に「開始ストップ」ボタンを押すと表示時間が0秒より大きいならカウントダウン中になる。

• カウントダウン中は、1秒ごとに表示時間を1秒ずつ減らす（T: 表示時間）。

• カウントダウン中に「開始ストップ」ボタンを押すと、カウントダウンを中断し時間設定中に戻る。

• カウントダウン中に、表示時間が0になるとアラーム中に移り、アラームがONになる。

• アラーム中に「開始ストップ」ボタンを押すと、アラームをOFFし時間設定中に戻る。

• キッチンタイマーの液晶画面には、初めは0秒表示されており、時間設定中になっている。

• 時間設定中において： 「10秒」ボタンを押すと、現在表示されている秒

数に10足されて表示される。 「クリア」ボタンを押すと、秒数は0になる

10秒 ｸﾘｱ開始ｽﾄｯﾌﾟ

キッチンタイマー

28

課題2（偶数）： 次の状態遷移図を書きなさい

• 時間設定中に「開始」ボタンを押すと表示時間が0秒より大きいならカウントダウン中になる。

• カウントダウン中は、1秒ごとに表示時間を1秒ずつ減らす（T: 表示時間）。

• カウントダウン中に「クリア」ボタンを押すと、カウントダウンをやめ表示時間を0にし時間設定中に戻る。

• カウントダウン中に、表示時間が0になるとアラーム中に移り、アラームがONになる。

• アラーム中に「クリア」ボタンを押すと、アラームをOFFし時間設定中に戻る。

• キッチンタイマーの液晶画面には、初めは0秒表示されており、時間設定中になっている。

• 時間設定中において： 「10秒」ボタンを押すと、現在表示されている秒

数に10足されて表示される。 「クリア」ボタンを押すと、秒数は0になる

10秒 ｸﾘｱ 開始

キッチンタイマー

29

今日のまとめ

• 要求とは、ビジネス面とシステム面がある

• 要求仕様書に書くべきこと、ISO/IEC/IEEE 29148• 要求仕様をしっかり書くために、要求モデルを使う

– ビジネス中心 ユースケース

– 機能中心 データフロー図

– データ中心 ER図

– ふるまい中心 状態遷移図

30