第1回　ソフトウェア工学とは

Transcription

1 ソフトウェア工学 1 第 3 回要求分析 (2) 2017 年 5 月 1 日 中島 1

2 授業内容 おさらい 要求とは 要求仕様書 要求の種別 仕様化 分析 機能要求 品質要求 ( 非機能要求 ) 2

3 ソフトウェア開発における要求分析 ( おさらい ) システム要求定義 設計 システム開発 システムテスト ソフトウェア要求分析 ソフトウェアテスト ソフトウェア外部設計 ソフトウェア結合テスト ソフトウェア内部設計 ソフトウェア単体テスト コーディング ソフトウェア開発 3

4 要求分析の難しさ ( おさらい ) 要求変更は必ず起きる 2 要求者の要求自体があいまい ユーザ要求 4 要求記述が低品質 要求仕様書 顧客 3 コミュニケーションが不完全 要求分析者 システム 1 ステークホルダにコンセンサスなし 発注元, 経営者, ユーザ, オペレータ, 保守者 5 環境の変化 ビジネス 運用 4

5 分析 : 欠陥の分類 ( おさらい ) 要求にはどんな欠陥があるのか 誤り : そもそも顧客が望んでいない 抜け : 顧客が暗黙に必要 / 必然的に必要なのに抜けている 矛盾 : 仕様同士 運用環境 ヒ シ ネスルールと整合していない あいまい : いろいろな意味に解釈できる 検証不可能 : 実現したかどうか確かめる手段がない 実現不可能 : 技術的 / コスト的に実現できない 5

6 要求分析のプロセス ( おさらい ) 顧客とのやりとりを中心に獲得 分析 仕様化 妥当性確認の繰り返し 要求仕様 モデルを利用 あいまいさ 誤り, 抜けへの挑戦! 現場調査インタヒ ュー 要求の獲得作業 獲得 利用 顧客要求の確認作業要求仕様利用 ( 要求モデル ) 要求書レヒ ューフ ロトタイフ テ モ 妥当性確認 分析 仕様化 6

7 授業内容 おさらい 要求とは 要求仕様書 要求の種別 仕様化 分析 機能要求 品質要求 ( 非機能要求 ) 7

8 要求仕様書 (ISO/IEC/IEEE 29148) 章 節 1. はじめに 1.1 目的 1.2 範囲 1.3 製品概要 製品展望 製品機能 ユーザ特性 制約事項 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 要求の種別 要求として記述するものは 1 機能要求 : システムは何をするのか 2 品質要求 : システムの品質はどうあってほしいのか 3 外部インタフェース : 他のシステムとのつながりはあるか 4 制約事項 : 実装に影響を与える決定事項は何か 9

10 要求の種別 : システム要求 カテゴリ 定義 例 機能要求 圧力が 40psiを超えたら 警告灯を点灯する (~する) 品質要求 (-ility) 外部インタフェース システムが ある種の条件下で示す観測可能なふるまいや処理の記述 システムが 何らかのふるまいをどの程度よく実行するかを示す記述 システムと他のドメイン間の接続を記述 制約事項開発者が利用できる選択肢を正当に制限する記述 新しいアイデアが登録されると システムはコーディネータに電子メールを送信する 保守し易い 信頼できる 使い易い 効率的な コマンドに対する応答が 3 秒以内, 初心者でも操作ができる ( 装置 ) からシグナルを読まなければならない ( 外部システム ) にメッセージを送らなければならない ( フォーマット ) でファイルを読まなければならない 指定する UIF ガイドラインに適合していなければならない提出電子ファイルは 10MB の大きさを超えてはならない 10

11 要求についてちょっと考えよう 酒類の通信販売を行う E-commerce サイト 1 機能要求 : どんなことができたらよいか 2 品質要求 : どんな品質を要求したいか ( 信頼できる 使い易い 効率的な ) 3 外部インタフェース : つながる他のシステムはあるか 4 制約事項 : 作り方に制約はあるか ( 法律, 規約, 使用言語, 使用するネットワークやデータベース, ) 11

12 授業内容 おさらい 要求とは 要求仕様書 要求の種別 仕様化 分析 機能要求 品質要求 ( 非機能要求 ) 12

13 なぜ要求モデルを使う? 形式性 : あいまいさ 矛盾 抜けなく書く できたら検証も 視覚性 : 図でユーザとコミュニケーション 2 要求者の要求自体があいまい ユーザ要求 4 要求記述が低品質 要求仕様書 顧客 3 コミュニケーションが不完全 要求分析者 システム 1 ステークホルダにコンセンサスなし 発注元, 経営者, ユーザ, オペレータ, 保守者 5 環境の変化 ビジネス 運用 13

14 分析 仕様化 : 要求モデル システム要求 1 機能要求 : 2 品質要求 : 3 外部インタフェース : 4 制約事項 : サービス中心 : ユースケース機能中心 : データフロー図データ中心 : ER 図ふるまい中心 : 状態遷移図 14

15 機能要求を表現する : サービス中心 ユースケース システムが提供するサービス それを使った業務の流れを, アクタとシステムとのやり取りとして, 記述する アクタ : システムのまわりの登場人物 ( 他システムも含む ) ユースケース名 : アクタ ユースケース ユースケース図 概要 : アクタ : 前提条件 : 記述 : 例外処理 : 事後条件 : 誰がシステムに動き出すきっかけを与えるかこのユースケースが起動される条件この業務のメインの流れを, システムとのやりとりとして記述この業務の流れこのユースケースが終了したときの条件 ユースケース記述 15

16 ユースケースの例 : 学会受付システム ユースケース図 ユースケース記述 ユースケース名 : 受付 参加者 受付 事前申込み 受付担当 概要 : 会場で参加者を受け付けるアクタ : 参加者事前条件 : シンポジウム当日であること記述 : 1. 申し込み既登録者かどうかを尋ねる 2. 申し込み既登録者の場合 登録者台帳に記載の氏名 所属を確認して 該当すればシンポジウム資料を渡して 受け付けを完了する 3. 申し込未登録者の場合 当日参加者台帳に氏名 所属 連絡先を記入する 4. つぎに参加費を支払ってもらう 参加費は会員 一般 学生の種類毎に 3000 円 5000 円 2000 円を徴収する 5. 参加費を徴収した後 シンポジウム資料を渡して 受け付けを完了する例外処理 : 事前条件 : シンポジウム当日であること 16

17 ユースケース書いてみよう 銀行 ATM ユースケース図 どんな登場人物がいる ( 他システムも含む )? どんなサービスがある? ユースケース記述 : 預金 を考える 誰の何からスタート? 時間順にユーザとシステムはどうやり取りする? 17

18 機能要求を表現する : 機能中心 データフロー図 (DFD) 要求機能を明確にする ( 入出力の明確化 ) 外部エンティティを明確にする 機能を分解する プロセス名 データ名 機能 データフロー テ ータストア名 エンティティ名 データストア ( データを蓄積する場所 ) 外部エンティティ ( データの発生源と出力先 ) エンティティ : 実体をもつもの 18

19 データフロー図の例 : 学会受付システム 参加者 登録者情報 参加費 受付 資料 領収書 参加者 参加者 登録者情報 登録済受付 登録者台帳 受付完了 資料 領収書 参加者 登録者情報 参加費 新規登録受付 登録者情報 参加費 参加費徴収 新規登録 19

20 データフロー図を書いてみよう 銀行 ATM ユースケースと 1 つ取り挙げよう そのユースケースは, どんな機能からなる? どんなデータの入出力があるのか? どんなデータベースがある? その機能はどんな機能に分解できる? 20

21 機能要求を表現する : データ中心 ER(Entity-Relationship) 図 問題領域のデータを把握する データ構造を記述する エンティティ名 エンティティ ( 実世界との対応関係をもつもの ) 関係名 関係 ( エンティティ間の関係 ) 属性名 属性 ( エンティティがもつデータ ) 1 個以上の対応関係 1 個の対応関係 21

22 ER 図の例 : 学会受付システム 参加者 参加する シンポジウム シンポジウム名 種類 所属 氏名 受付ける シンポジウム番号 受付担当 氏名 22

23 ER 図を書いてみよう 銀行 ATM: 銀行口座と利用者 1 銀行口座はどんなデータからなる? 2 利用者 ( 顧客 ) 情報とはなにからなる? 3 銀行と利用者の関係は? ヒント エンティティ : 銀行口座, 利用者 属性 : それぞれの属性 12 関係 : 3 23

24 機能要求を表現する : ふるまい中心 状態遷移図 システムのふるまいを記述する 〇〇状態で が起きたら ~ をして 状態に移る システムの状態を明らかにする 状態名 状態 ( モート 制御状態 表示状態 ) 初期状態 イヘ ント名 [ 条件 ]/ アクション名 状態遷移 ( 状態間の移動 ) 子親 状態の階層化 after(x 秒 ) タイムアウト (X 秒たったら遷移する ) 状態の並列化 24

25 ふるまいの記述 : 状態遷移図 例 ) 学会受付システム 参加者 登録状態 登録済 未登録 キャンセル [ 未受付 ]/ 返金 キャンセル [ 未受付 ] 未入金 入金 入金済 未受付 受付 [ 登録済 ] 受付済 受付状態 25

26 状態遷移図を書いてみよう ストップウォッチ LB RB LB: 計測開始 / 停止 RB: クリア ( 停止時 )/ ラップ ( 計測時 ) 26

27 課題 学籍番号が奇数の人は問題 1, 偶数の人は問題 2 ( 間違うと採点しません ) レポートには, 氏名, 学籍番号, 問題番号を書くこと 5/9( 火 ) 13:00 までに研究棟 14G32 ポストに提出 ( または 5/9 授業に持ってくること ) 27

28 問題 1( 奇数 ): 次の状態遷移図を書きなさい キッチンタイマー 10 秒クリア 開始ストッフ キッチンタイマーの液晶画面には 初めは0 秒表示されており 時間設定中になっている 時間設定中において : 10 秒 ボタンを押すと 現在表示されている秒数に10 足されて表示される クリア ボタンを押すと 秒数は0になる 時間設定中に 開始ストップ ボタンを押すと表示時間が 0 秒より大きいならカウントダウン中になる カウントダウン中は 1 秒ごとに表示時間を 1 秒ずつ減らす (T: 表示時間 ) カウントダウン中に 開始ストップ ボタンを押すと カウントダウンを中断し時間設定中に戻る カウントダウン中に 表示時間が 0 になるとアラーム中に移り アラームが ON になる アラーム中に 開始ストップ ボタンを押すと アラームを OFF し時間設定中に戻る 28

29 課題 2( 偶数 ): 次の状態遷移図を書きなさい キッチンタイマー 10 秒クリア開始 キッチンタイマーの液晶画面には 初めは 0 秒表示されており 時間設定中になっている 時間設定中において : 10 秒 ボタンを押すと 現在表示されている秒数に 10 足されて表示される クリア ボタンを押すと 秒数は 0 になる 時間設定中に 開始 ボタンを押すと表示時間が 0 秒より大きいならカウントダウン中になる カウントダウン中は 1 秒ごとに表示時間を 1 秒ずつ減らす (T: 表示時間 ) カウントダウン中に クリア ボタンを押すと カウントダウンをやめ表示時間を 0 にし時間設定中に戻る カウントダウン中に 表示時間が 0 になるとアラーム中に移り アラームが ON になる アラーム中に クリア ボタンを押すと アラームを OFF し時間設定中に戻る 29

30 今日のまとめ 要求とは ビジネス面とシステム面がある 要求仕様書に書くべきこと ISO/IEC/IEEE 要求仕様をしっかり書くために 要求モデルを使う ビジネス中心 ユースケース 機能中心 データフロー図 データ中心 ER 図 ふるまい中心 状態遷移図 30