要求分析入門 1 情報システム構築の最初に 2005年11月9日 海谷 治彦

目次 (情報)システムの意義と役割 問題と解法 問題陳述書，業務仕様書，要求仕様書 問題陳述書から業務仕様書へ． 例題 演習について

情報システムの納品先 システムは現実世界に埋め込まれ(割り込み)，利用されることを期待される． 現実世界 その情報システム無しで成立している世界 ハードウェア，装置 人間や動物 物理法則，自然環境 法令，慣習 既存の(情報)システム as-is とも呼ばれます．

何故，新規システムが必要か？ 現実世界に問題があるから． 現実世界を改善したいから． どちらにしろ，システムが埋め込まれることで，現実世界は変化します．

IT技術の変化 ご存知の通り，IT技術の変化は激しい． それ以上に自身が把握している技術は狭い． ある時点での技術をもとに問題解決や改善を行っても，次につなげることができない． 現状技術に関係無く，世界と問題を把握することが必要．

実験パート2の目的 どんな情報システム(プログラム等)を構築すべきかを決定するまでの作業を学ぶ． いわゆるシステムアナリスト(SE)の仕事． 上流工程とも呼ばれる． 作業順序的にプログラム開発よりも先にくるから．

システム開発と情報伝達 顧客 システムがほしい人，技術には疎い場合もアリ アナリスト (SE) 技術の知識はあるが顧客の仕事に精通してはいないのが普通 開発者 設計者とかプログラマとかテスタとか

書類による伝達 問題陳述書 Problem Statement (問題) 顧客 要求仕様書 Requirements Specification (要求) アナリスト (SE) 業務仕様書 Business Specification (業務) 開発者

書類の概要 問題陳述書 (Problem Statement) 業務仕様書 (Business Specification) 顧客が述べた自分の問題点や改善したいことを文書にしたもの． 業務仕様書 (Business Specification) 問題や改善点に関連した世界の一部を記述したもの． 世界全てを記述することは無理． 要求仕様書 (Requirements Specification) 世界の何処に，どのような技術を埋め込み，その技術は何を達成するかを明示したもの． 要は作るべき情報システムの機能や性能等． コレをもとにプログラムや人工物を作成する．

誰がどう書くか？ 結論からいえば全てSEが書かなければならない． 問題陳述書 業務仕様書 要求仕様書 顧客に話を聞いたり，世界を観察したりして書かなければならない． 業務仕様書 問題に関連する世界の一部を明らかにする． システム導入によっての影響を見通すため． 要求仕様書 開発者への指示書となるため，実現可能な要求でなければならない．

何を書くか？ 問題陳述書 業務仕様書 要求仕様書 基本的には顧客等，システムを欲している人の問題を箇条書きで列挙する． 問題発生に関係している作業手順を箇条書きに書く． 問題発生にかかわる処理や行動の列と考えてよい． 当面，解決案は書かない． ⇒ いくつかの案をあとで吟味するため． 手順内のどの作業が問題と深く関わっているかマークしておく． 階層的に書いてよい． 要求仕様書 次回話します・・・

業務の階層的記述 is-a (一般化，具体化) has-a (部分，全体) ある作業に複数の具体的なバリエーションがある場合等の階層化． 例えば右記． Javaの super/subとほぼ同じ． 条件を書いてないif文分岐ともみなせる． has-a (部分，全体) ある作業がさらに細かい作業に分割でき場合の階層化． 例は右記． サブルーチン化 と考え方がにている． 全てが遂行される わけではない． 3. 料金を支払う． <| 銀行振り込み． <| クレジットカードで支払う． <| 着払い． 2. 格安航空券を買う． <> 格安な代理店を探す． <> 券を予約． <> 料金を支払う． <> 券を受け取る． <> 領収書を受け取る． <| や <> はUMLの記法をなんとなし似せてるだけです．

それぞれの対応は？ 問題1 問題2 問題3 業務1 業務2 業務3 要求1 要求2 ある問題は複数業務に関係するかもしれないし(問題3)， 複数の問題に関わる業務も存在しうる(業務2)． 問題解決のため，直接の問題発生部分以外にIT支援が必要かもしれない． 複数の問題を解決しうる要求もあれば，解決に複数の要求を必要とする問題もあるだろう． 情報システムでは解決できない問題もあるかもしれません． 問題1 問題2 問題3 業務1 業務2 業務3 要求1 要求2

問題と業務の対応例 業務 問題 問題 is-a(<|)もhas-a(<>)もなるだけ，深い階層と関係付ける． ： 3. 格安航空券を買う． <> 格安な代理店を探す． <> 券を予約． <> 料金を支払う． <| 銀行振り込み． <| クレジットカード． <| 着払い．[1] <> 券を受け取る．[2] 問題 [1] 予約を反故にする客がいる． 問題 [2] 出発前に券が届かない． is-a(<|)もhas-a(<>)もなるだけ，深い階層と関係付ける． 具体的かつ限定的に問題の原因を把握するため． とはいえ，共通に問題に関連すれば，浅い階層と関連付けてもよい．

例題 ある高校の図書館に情報システムを導入． 実際の図書館は既にこのような問題点を解決済かもしれませんが・・・

問題陳述書 生徒，図書委員，司書さんに話を聞いたところ以下のような問題を示されました． 問題陳述書: [1] 読みたい図書がみつからない． [2] 手続きをしないで持ち出す輩がいる． [3] 貸し出し手続きがめんどー． [4] 本をなかなか返さない輩がいる． [5] 行ったら貸し出し中で無駄足になる． [6] 貸し出し中なのか，書架にあるのか，館内で誰か読んでるのかすぐに把握できない． [7] ボロくなって読めない本がある． [8] 読みたい本が蔵書されない．

業務A: [1]に関係 業務仕様書A: (図書を探す) 1. 利用者が図書館にいく． 2. 該当図書のありそうな書架を見つける．[1] <| 図書委員が居れば場所を聞く． <| ジャンルをもとに館内地図をみる． <| インデクスカード(紙)で調べる． 3. 書架で図書をサーチ．[1] <| 50音順に書架を眺める． <| 題名を正確に知らないので背表紙を眺める． [1] 読みたい図書がみつからない．

業務B: [2],[3]に関係 業務仕様書B: (図書を借りる) 1. 生徒が借りたい図書を手に取る． 2. 貸し出し窓口に行って図書委員に手続きを依頼する．[3] <> 借りたい図書を提示． <> 自身が誰かを提示． <> 図書委員が借りたことを記録． 3. 図書を持って図書館を退出する．[2] [2] 手続きをしないで持ち出す輩がいる． [3] 貸し出し手続きがめんどー．

業務文書化のTips & Rules 基本的にはインスタンスの分析である． 作業者の立場になって記述． 「図書館一般」ではなく「具体的な顧客の(勤める)図書館」 作業者の立場になって記述． 実際には「顧客」に実際と合っているかを要確認． 主語，目的語，場所，時間等はなるだけ省かない． 既存の道具を利用しているならそれもなるだけ記述． 問題も業務もラベル付け(番号付け)が重要． どこのことを言ってるかわかりやすいように． 作業順序について 順序性が強いものは番号付けで． 特に順序が関係ないものは箇条書きで． 階層化して記述する場合，is-aとhas-aの区別を <| is-a 一般化，具体化の関係 <> has-a 部分，前回の関係

さて，演習1です 残りの問題([4]～[8])に対応する業務仕様書を記述してください． 不足する情報は「自分が顧客の立場」となって補填してください． 業務記述のラベルはCから始めてください． 前述の解答例(業務A,B)を拡張して[4]以降の問題に対応する業務を書いても結構です． ラベルは別にしてください． 提出はテキストファイルでお願いします． 提出は指定のウエブページより． 時間は1時間くらいとなります．