Tweet
Tweet

Slide 1

Slide 1 text

現状分析→価値開発→仕様化＆テスト設計 の展開事例解説 仕様＆テスト編 1 みずのり（みずののりゆき） ＠TOC/TOCfE北海道 RDRA MeetUp、TEF道など （ペーパー）プロトタイピングな仕様化とテストの具体例紹介

Slide 2

Slide 2 text

自己紹介 2 好きなもの：汎用的スキル（テストや論理思考、TOC）、趣味：テスト中心のモデリング研究 発表や公開している内容は以下。※過去6年程度のみ RDRA関連（神崎さんとの勉強会から実践で学んだもの） ・RDRA+プロトタイピングおよび仕様化時に役立つ技術、事例紹介 ・伝統的食品工場エンジニアリング会社が挑むDXへのビジネスアイデアを RDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義（DevSumi関西2020） ・ 今回の発表ネタ、長いタイトルなので省略（JaSST’21東京チュートリアル） TOC（制約理論：Theory of Constraints）関連（安達さんとワークショップ作成） ・SaPIDTOC～未来予想型チーム運営ワークショップ（JaSST’18東京チュートリアル実施） ・プロジェクトマネジメントの概要とCCPMによる工期短縮の仕組み ・提案を検証する技術（TOC マフィアオファー（URO）活用技術） ・SQiP2014：CCPMの考え方を活用したテストフェーズにおける課題解決 ～課題発見、解決までのケーススタディ～ ソフトウェアテスト/テスト自動化関連 ・（共著）InSTA2019＠西安：Coexistence of test execution efficiency and test ・ET⁻WEST2018：なぜ組込みシステムにおけるテストは難しいのか ～ 2つのテストアーキテクチャによってテストを組立てる ～ ・ （共著） InSTA2018＠Sweden：Proposal for Enhancing UTP2 with Test Aspects ・ （共著） InSTA2017＠東京：Test Conglomeration - Proposal for Test Design Notation like Class Diagram ・JaSST’17関西：納得できるテストをつくるアプローチ ・STAC2015：自動家は見た～自動化の現場の真実～ ・テストカタマリーの紹介/活用したテスト設計プロセス案

Slide 3

Slide 3 text

全体の流れを再確認 3 そして新図書館システムへ 既存図書館システム ASISシステム可視化 ①RDRA 【神崎】 TOBEシステム可視化 ③RDRA 【神崎】 TOBEシステム ④仕様化with Test 【水野】 ② SaPID 【安達】 TOBE 図書館システムによる 運営の効果と価値の可視化 ASIS 図書館システムによる 運営の効果と価値の可視化 イマココ

Slide 4

Slide 4 text

全体の流れ：RDRAから仕様化へ 4 今回の仕様化については、図書館システムにおける「会員登録」に絞って具体例を交えて紹介を行います。 ※RDRAがあることで対象を絞り込んで計画がやりやすくなります 窓口 会員 期限管理 会員登録 [会員管理：業務] 窓口 会員 返却 窓口貸出 書架 図書 館員 蔵書 [貸出・返却：業務] [蔵書管理：業務] 会員 棚卸 書籍 補充 書籍店 蔵書 司書 [窓口貸出：BUC] 蔵書を 貸出す 書架から 本を探す 蔵書の貸出 を登録する 会員 貸出 登録 蔵書 貸出 図書 図書 館員 貸出制限 会員登録 会員カード を作成する 図書 館員 会員IDを 発行する 会員 [会員登録：BUC] 貸出図書 を返却す る 返却図書を 書架に返す 貸出図書の返 却を登録する 会員 返却 登録 貸出 図書 図書 館員 貸出 予約 蔵書 [返却：BUC] [期限管理：BUC] 貸出期限を 確認する 日次 貸出 図書 貸出期限 切れ通知 会員 窓口 図書館 会員 貸出・ 返却 書籍店 司書 蔵書 管理 書架 蔵書 会員 管理 図書 館員 司書 補充リスト を作成する 書籍の発 注を行う 司書 [書籍補充：BUC] 書籍発注 書籍発 注登録 蔵書を登録し ラベルを張る 蔵書を登 録する 蔵書 登録 蔵書 書籍ラベル ココやる

Slide 5

Slide 5 text

全体の流れ：RDRAから仕様化へ 5 選択理由：次のようなターゲットとなる。 ・全体に影響のありそうなところ ・最初に小さくMVP構築できそうなところ ・業務のメイン部分でキッチリ作ったほうがよいところ ・多くの方の関心の強いところ 窓口 会員 期限管理 会員登録 [会員管理：業務] 窓口 会員 返却 窓口貸出 書架 図書 館員 蔵書 [貸出・返却：業務] [蔵書管理：業務] 会員 棚卸 書籍 補充 書籍店 蔵書 司書 [窓口貸出：BUC] 蔵書を 貸出す 書架から 本を探す 蔵書の貸出 を登録する 会員 貸出 登録 蔵書 貸出 図書 図書 館員 貸出制限 会員登録 会員カード を作成する 図書 館員 会員IDを 発行する 会員 [会員登録：BUC] 貸出図書 を返却す る 返却図書を 書架に返す 貸出図書の返 却を登録する 会員 返却 登録 貸出 図書 図書 館員 貸出 予約 蔵書 [返却：BUC] [期限管理：BUC] 貸出期限を 確認する 日次 貸出 図書 貸出期限 切れ通知 会員 窓口 図書館 会員 貸出・ 返却 書籍店 司書 蔵書 管理 書架 蔵書 会員 管理 図書 館員 司書 補充リスト を作成する 書籍の発 注を行う 司書 [書籍補充：BUC] 書籍発注 書籍発 注登録 蔵書を登録し ラベルを張る 蔵書を登 録する 蔵書 登録 蔵書 書籍ラベル 上位の分析があると 判断しやすい SaPID検討より

Slide 6

Slide 6 text

全体の流れ：RDRAから仕様化へ 6 窓口 会員 期限管理 会員登録 [会員管理：業務] 窓口 会員 返却 窓口貸出 書架 図書 館員 蔵書 [貸出・返却：業務] [蔵書管理：業務] 会員 棚卸 書籍 補充 書籍店 蔵書 司書 [窓口貸出：BUC] 蔵書を 貸出す 書架から 本を探す 蔵書の貸出 を登録する 会員 貸出 登録 蔵書 貸出 図書 図書 館員 貸出制限 会員登録 会員カード を作成する 図書 館員 会員IDを 発行する 会員 [会員登録：BUC] 貸出図書 を返却す る 返却図書を 書架に返す 貸出図書の返 却を登録する 会員 返却 登録 貸出 図書 図書 館員 貸出 予約 蔵書 [返却：BUC] [期限管理：BUC] 貸出期限を 確認する 日次 貸出 図書 貸出期限 切れ通知 会員 窓口 図書館 会員 貸出・ 返却 書籍店 司書 蔵書 管理 書架 蔵書 会員 管理 図書 館員 司書 補充リスト を作成する 書籍の発 注を行う 司書 [書籍補充：BUC] 書籍発注 書籍発 注登録 蔵書を登録し ラベルを張る 蔵書を登 録する 蔵書 登録 蔵書 書籍ラベル これだけだと 作るまでは厳しい 今回の仕様化については、図書館システムにおける「会員登録」に絞って具体例を交えて紹介を行います。 ※RDRAがあることで対象を絞り込んで計画がやりやすくなります

Slide 7

Slide 7 text

仕様づくり（ペーパープロトタイピング仕様化withテスト） 7 紹介するもの： 「会員登録」業務に対する仕様化withテスト 実際にRDRAを作った後に依頼されてやることの多い実際の仕事相当の内容をリアルに紹介 紹介する流れ： ・仕様検討における問題 ～Vol0 ケーススタディより～ ・今回紹介するもの（仕様化のテンプレートと流れ） ・仕様化検討のケーススタディ（一例） Vol1．ヒアリングのための仮説を作る Vol2．ヒアリング結果から、仕様を完成させる Vol3．仕様に対するテスト設計からフィードバックする ・まとめ

Slide 8

Slide 8 text

仕様検討における問題：Vol0 ケーススタディ 8 仕様Vol0にてありそうな問題を紹介します。 ※SaPIDもRDRAもない状況を考慮したものです。 具体例紹介

Slide 9

Slide 9 text

仕様の例：Vol0 残念なケース 9 メモ：具体例 部分には↑に バーを入れてます

Slide 10

Slide 10 text

仕様テーマ：会員登録の実施 10 Vol0 よくあるインプット（会話の内容込み）： （会話で残される情報） 元々会員カードで 運用していましたが、 カードを忘れる人が多いので スマホでも貸し出しが できるとよいです あ、AIとかもやりたいですが 簡単に行けますかね ※要件定義も大中小で書かれた簡単な表のみ

Slide 11

Slide 11 text

仕様テーマ：会員登録の実施 11 仕様Vol0（残念な仕様）： ＜会員の登録/会員カード発行＞ ・図書館を使用する（書籍の貸し出しをする）ためには、事前に会員登録をする ・会員登録ができること、会員登録の条件は既存の会員条件と同じ ・会員カードは新規システムでも発行する、カード発行されると市内の全図書館で使用できる ・会員は会員カードを使用することでセルフレジで貸し出しができ、予約情報が記録される ・会員カード発行だけではWeb/スマホでは使えないが、貸し出しには使用できる ＜Web向け会員ID（Web会員ID）の登録＞ ・Web向け会員IDを持つことによってWebでの書籍検索と予約ができる ・会員は自分でWeb会員IDを申請して獲得ができること、図書館でもWeb会員IDを申請ができること ・会員カードを忘れる人が多いので、スマホでもカード情報を呼び出して貸し出しをすることができること いろいろ 突っ込みアリ

Slide 12

Slide 12 text

仕様テーマ：会員登録の実施 12 残念な仕様の結果… ＜既存の会員対応が後手にまわり不備が発生＞ ・既存のカード体系を考慮せずに新規カード/システムを作ってしまい、図書館統合に対応できない 新旧のカード体系が大きく変わり、既存カード対応を最後に無理に追加するなどで複雑化＆不具合発生へ ・既存カードを持った人は再登録して新規カードに切り替えないとWebを使用できない ＜（SaPIDで検討したような）ToBe対応方針が達成できない＞ ・図書館員に依頼してWeb登録する手順が入り、図書館員の負担が増えてしまう ・カードのみで図書館を使う会員に対してWebでのなりすまし登録が発生する ・Webシステム側に安易に個人情報が保存された状況となりセキュリティ上の問題が発生 え、先月カード作ったばかり なのにまた再発行が必要？ 利用者 図書館員 システム変わっても 結局忙しい… 旧カードも 使うのかよ… 開発者

Slide 13

Slide 13 text

仕様テーマ：会員登録の実施 13 残念な仕様の結果… ＜既存の会員対応が後手にまわり不備が発生＞ ・既存のカード体系を考慮せずに新規カード/システムを作ってしまい、図書館統合に対応できない 新旧のカード体系が大きく変わり、既存カード対応を最後に無理に追加するなどで複雑化＆不具合発生へ ・既存カードを持った人は再登録して新規カードに切り替えないとWebを使用できない ＜（SaPIDで検討したような）ToBe対応方針が達成できない＞ ・図書館員に依頼してWeb登録する手順が入り、図書館員の負担が増えてしまう ・カードのみで図書館を使う会員に対してWebでのなりすまし登録が発生する ・Webシステム側に安易に個人情報が保存された状況となりセキュリティ上の問題が発生 え、先月カード作ったばかり なのにまた再発行が必要？ 利用者 図書館員 システム変わっても 結局忙しい… 旧カードも 使うのかよ… 開発者 色々達成できず…もう少しうまいやり方ができるとよいのかも

Slide 14

Slide 14 text

仕様検討における問題：Vol0 ケーススタディ 14 仕様Vol0にてありそうな問題を紹介しました。 ・表形式の要件、会話内で出てくる一部に特化した意見がインプット ・仕様としても箇条書きで8行程度（これに意味があるか不明） ・結果として残念なことが多くなり… SaPIDで紹介された方針は達成できない

Slide 15

Slide 15 text

今回紹介するもの 15 ・ユーザー、開発者とヒアリングしながら仕様化を進めます ・「プロトタイピング仕様化（withテスト）」とでも呼んでおきます ※プロトタイピングと言っておりますが、実際にはペーパープロトタイプを使います ・上位の情報（SaPID/RDRA）もあればより有効的な活動ができます ・仕様に対してテスト設計を行うことで、仕様や業務手順へフィードバックもします ・仕様ドキュメントの書き方自体は以下のテンプレートを段階的に埋めていく形式を使っています ※みなさんの環境にあわせてカスタマイズしてください ・今回は段階的な打合せとドキュメントの更新を経て仕様化する例を紹介します プロトタイピング な仕様 開発者 ユーザー 運用 実現 テンプレートタイトル 内容 背景 仕様（新規作成、変更）が必要とされる背景や AsIs状況を書きます。 課題・やりたいこと 解決したい課題ややりたいことを書きます。 検討・検証シナリオ 業務のパターンとヒアリング時にケーススタディ を行うためのシナリオを特定します。 実現方針 人の運用でカバーを含めての実現方法を書きます。 （調整事項） 中間ヒアリングでの質問事項。最後には消えます。 仕様 実装に必要な情報を箇条書きなどでまとめます。 テスト向け情報 仕様やシナリオに対するテスト設計を書きます。

Slide 16

Slide 16 text

今回紹介するもの 16 ■（参考）開発者、ユーザー双方の傾向 開発者：システムの知識はあるが、業務の知識はない。実現方法に興味が強い。運用への興味が薄いことが多い。 ・手持ちの or 思いついた実現手段が運用にも適していて何とかなると思いこみやすい ・実装するもの≒既に合意されているもの と思いこみやすい ・説明が雑なことが多い、開発者のみ伝わる表現（UMLや概念モデルとか）で伝わると考えている ・（極端なケース）ユーザーとの話をするのが無駄だと思っている人もいる ユーザー：業務の知識はあるが、システムや開発の知識はない場合が多い。運用と業務効率化に興味が強い。 ・開発者の言っていることが何かわからない、理解できないことが多い ・知っている範囲で実現する手段を提示し、知らない手段には耳を貸さないこともある ・ものが出てくるまで/運用を開始するまで実感がないことが多い 逆に運用を開始して使い始めた後に意見が大量に出ることが多い ・「自分の範囲の仕事」で語ることが多く、課題を分けたり 業務フロー的に分割・整理して話すことができる人は少ない プロトタイピング な仕様 開発者 ユーザー 運用 実現

Slide 17

Slide 17 text

今回紹介するもの（参考資料） 17 とある書籍より、今回の進め方の参考となる概念イメージ →仕様編の紹介範囲 目的を特定する 主要なシナリオ を特定する アプリケーション の全体像を描く 主要な課題を 特定する 解決策の候補 を出す 上位の要件や情報が存在しない場合は 安達さん神崎さんのお話を聞きましょう 全体の整理は RDRAで実施してもらっているので 個々の検討に専念します

Slide 18

Slide 18 text

仕様化検討のケーススタディ 18 今回は、図書館システム会員登録とWebで使用するための会員ID登録について仕様化のケーススタディをします ・仕様化検討のケーススタディ（一例） Vol1．ヒアリングのための仮説仕様を作る Vol2．ヒアリング結果から、仕様を完成させる Vol3．仕様に対するテスト設計からフィードバックする ・今回のケーススタディにおける進め方は以下になります。 ※必ずしもこの流れにはなりませんので注意してください… SaPID情報 仕様 Vol1 RDRA情報 ヒアリングのための 仮説仕様を作る ・背景 ・課題・やりたいこと ・検討・検証シナリオ ・調整事項 ヒアリング結果から 仕様を完成させる ・全体更新 ・実現方針 ・仕様 仕様 Vol2 ユーザー/顧客 ヒアリング ヒアリング 結果 仕様に対する テスト設計から フィードバックする ・テスト向け情報 ・全体更新 仕様 Vol3 必要に応じて ユーザー/顧客 との共有 テスト 設計 テスト 設計結果

Slide 19

Slide 19 text

仕様化検討のケーススタディ： Vol1．ヒアリングのための仮説仕様を作る 19 ・上位の情報（RDRA、SaPID）があれば便利 ・背景となる情報があれば記載して、課題・やりたいことを仮でまとめる ・対象の業務で検討が必要なバリエーションを出し、議論する代表の業務シナリオを決める ・（RDRAの業務フローがある場合）業務フローを1段階詳細化し、具体的にシステムを使う箇所を特定する ・業務フローに沿った流れを確認するために、特定の情報だけ記載したペーパープロトタイプを用意する ・上記を作成する際に、調整事項（実現に対する課題）を特定してまとめる ・全体として、論点が異なるものは別検討や拡張仕様でまとめる方針として分ける ・上記がまとまり次第、「調整事項（実現に対する課題）」を確認するためヒアリングを行う SaPID情報 仕様 Vol1 RDRA情報 ヒアリングのための 仮説仕様を作る ・背景 ・課題・やりたいこと ・検討・検証シナリオ ・調整事項 ヒアリング結果から 仕様を完成させる ・全体更新 ・実現方針 ・仕様 仕様 Vol2 ユーザー/顧客 ヒアリング ヒアリング 結果 仕様に対する テスト設計から フィードバックする ・テスト向け情報 ・全体更新 仕様 Vol3 必要に応じて ユーザー/顧客 との共有 テスト 設計 テスト 設計結果

Slide 20

Slide 20 text

仕様化検討のケーススタディ： Vol1．ヒアリングのための仮説仕様を作る 20 テンプレートに従って進める例を紹介します。 具体例紹介

Slide 21

Slide 21 text

仕様の例：Vol1 ヒアリングのための仮説仕様 21

Slide 22

Slide 22 text

仕様テーマ：会員登録の実施 22 Vol1 インプット： RDRA情報 SaPID情報 窓口 会員 期限管理 会員登録 [会員管理：業務] 会員カード を作成する 図書 館員 Web会員ID を発行する 会員 [会員登録：BUC] 会員 会員登録 会員登録 条件 会員 登録 会員登録

Slide 23

Slide 23 text

仕様テーマ：会員登録の実施 23 Vol1 インプット：ざっくり状況の特定（だいたいの目安） →厄介そうな部分はある程度把握しておく システム設計要 図書館の統合 CMSは別スコープ とする 業務調整 販売チェーン連携 図書館員の業務 負荷の大改善 トレードオフ要 RFIDシステムの 前提

Slide 24

Slide 24 text

仕様テーマ：会員登録の実施 24 Vol1 ・テンプレートに対して、前半部分を中心に仮説的な仕様をまとめていきます。 テンプレートタイトル 内容 背景（必要時） 仕様（新規作成、変更）が必要とされる背景や AsIs状況を書きます。 課題・やりたいこと 解決したい課題ややりたいことを書きます。 検討・検証シナリオ 業務のパターンとヒアリング時にケーススタディ を行うためのシナリオを特定します。 実現方針 人の運用でカバーを含めての実現方法を書きます。 （調整事項） 中間ヒアリングでの質問事項。最後には消えます。 仕様 実装に必要な情報を箇条書きなどでまとめます。 テスト向け情報 仕様やシナリオに対するテスト設計を書きます。 ここまでをまとめる のが目標となる この2つは前半が決まらないと 無駄になるので考えない 説明補足

Slide 25

Slide 25 text

仕様テーマ：会員登録の実施 25 背景： ・図書館システムの導入に対して事前に会員登録を行っている→今後も行う ・前提：すでに会員カードの登録している会員がいる状況、新システムが不要な人もいる ・システム導入前から使用している現会員カードについて…？（たぶん使えたほうがよいが確認） ・図書館を統合するシステムとなるが、現状の会員の仕組みは…？（仕組みが異なると利用者の影響が大きい） 課題・やりたいこと： ・新規登録者にはWeb会員ID、仮パスワード、（新規のカードが必要なら？）会員カードを発行したい ※調整：Webで会員カード発行まですべての登録はできない想定で仮検討してます ・すでに会員で会員カードを持っていて、Webを使わない方は元の会員カードのみで運用継続（しますか？） ・すでに会員で会員カードを持っている人は、利用者本人がWeb画面でWeb会員ID登録ができるようにしたい ※調整：この場合、会員カードを発行して手に入れる必要があるか確認 ・Web会員IDを登録することで、スマホ（ブラウザ/アプリ）で表示してカードの代わりに使用できる ＜用語整理＞ ・会員（カードを持つ人）、Web会員IＤ（Webで使用するための）：それぞれ個別に登録が必要という想定 ＜別論点の課題とする＞ ・会員カードを忘れる人が多いので、スマホでも貸出ができる仕組みを作る（貸出処理は別仕様で整理） ・既会員で会員カードを持っている人が継続的に運用ができるかどうか確認 ・会員情報を変更するような場合にWebから可能にする方法は別途整理する テンプレートタイトル 内容 背景（必要時） 仕様（新規作成、変更）が必要とされる背景や AsIs状況を書きます。※assumptionやconstraintも対象 課題・やりたいこと 解決したい課題ややりたいことを書きます。

Slide 26

Slide 26 text

仕様テーマ：会員登録の実施 26 背景： ・図書館システムの導入に対して事前に会員登録を行っている→今後も行う ・前提：すでに会員カードの登録している会員がいる状況、新システムが不要な人もいる ・システム導入前から使用している現会員カードについて…？（たぶん使えたほうがよいが確認） ・図書館を統合するシステムとなるが、現状の会員の仕組みは…？（仕組みが異なると利用者の影響が大きい） 課題・やりたいこと： ・新規登録者にはWeb会員ID、仮パスワード、（新規のカードが必要なら？）会員カードを発行したい ※調整：Webで会員カード発行まですべての登録はできない想定で仮検討してます ・すでに会員で会員カードを持っていて、Webを使わない方は元の会員カードのみで運用継続（しますか？） ・すでに会員で会員カードを持っている人は、利用者本人がWeb画面でWeb会員ID登録ができるようにしたい ※調整：この場合、会員カードを発行して手に入れる必要があるか確認 ・Web会員IDを登録することで、スマホ（ブラウザ/アプリ）で表示してカードの代わりに使用できる ＜用語整理＞ ・会員（カードを持つ人）、Web会員IＤ（Webで使用するための）：それぞれ個別に登録が必要という想定 ＜別論点の課題とする＞ ・会員カードを忘れる人が多いので、スマホでも貸出ができる仕組みを作る（貸出処理は別仕様で整理） ・既会員で会員カードを持っている人が継続的に運用ができるかどうか確認 ・会員情報を変更するような場合にWebから可能にする方法は別途整理する どちらでもできるけど、どちらがよいか？ を議論できるように、テンプレ内容を まとめながら質問箇所を出す 説明補足

Slide 27

Slide 27 text

仕様テーマ：会員登録の実施 27 検討・検証シナリオ： ・RDRA成果物を踏まえたうえでユーザーと議論します 説明補足 窓口 会員 期限管理 会員登録 [会員管理：業務] 会員カード を作成する 図書 館員 Web会員ID を発行する 会員 [会員登録：BUC] 会員 会員登録 会員登録 条件 会員 登録 会員登録 ルールや手続きの変わるバリエーションを （すべてではないが）洗い出したい 例：本の貸し出しバリエーションと条件 条件＠RDRA ・バリエーションの組み合わせ ・バリエーションと状態の組み合わせ ※バリエーションはツリー分析など 条件はデシジョンテーブルでも表現可 狙いどころ：議論が発散しすぎないようにする 目的を見失わないようにする やること ：業務のバリエーションを考え、 特定のシナリオへ整理する テンプレートタイトル 内容 検討・検証シナリオ 業務のパターンとヒアリング時にケーススタディ を行うためのシナリオを特定します。

Slide 28

Slide 28 text

仕様テーマ：会員登録の実施 28 検討・検証シナリオ： ・RDRA成果物を踏まえたうえでユーザーと議論します 説明補足 窓口 会員 期限管理 会員登録 [会員管理：業務] 会員カード を作成する 図書 館員 会員 [会員登録：BUC] 会員 会員登録 会員登録 条件 会員 登録 会員登録 会員可能な住所 Z市＋近隣町 上記以外 バリエーションを仮検討 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない Web会員IDの登録場所（仮説込み） 図書館員が会員登録/カード作成時に仮登録？ 会員が自分でWeb上で登録 狙いどころ：議論が発散しすぎないようにする 目的を見失わないようにする やること ：業務のバリエーションを考え、 特定のシナリオへ整理する ※参考（他の懸念事項もここで出てくる） ・Webで会員カードの申請までする？ →開発側としてやりたくないので仮で除外 ・図書館統合の場合、登録図書館カードを 切り替える際にどうするか？ 既存カードの扱いはどうか？ Web会員ID を発行する 会員登録（カード）申請場所 図書館（窓口） Web

Slide 29

Slide 29 text

仕様テーマ：会員登録の実施 29 検討・検証シナリオ： ・ステークホルダと議論をやりやすいシナリオを導出します 会員可能な住所 Z市＋近隣町 上記以外 バリエーション 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない Web会員ID場所（仮説込み） 図書館員が会員登録/カード作成時に仮登録？ 会員が自分でWeb上で登録 目先で議論しやすいシナリオ（条件）を選定 表示条件整理 #1 #2 #3 会員状況 既に会員、Web会員ID登録済 対象外 - - - 既に会員、Web会員ID登録なし 対象 〇 〇 - まだ会員ではない 対象 - - 〇 会員可能な住所 Z市＋近隣町（会員対象） 対象 〇 〇 〇 上記以外（会員非対象） 画面案だけ確認 - - - Web会員ID登録場所 図書館員が仮登録？ 対象 〇 - - 会員が自分でWeb上で登録 対象 - 〇 〇 シナリオ ひとまず採用 〇 〇 〇 非採用 - - - 議論時に使用する代表シナリオ #1 すでに会員の人が図書館受付で図書館員にWeb会員ID依頼？ #2 すでに会員の人が自分でWeb上でWeb会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆Web会員ID同時登録？ （該当住民のみ、該当住民でない場合は会員非対象とする）

Slide 30

Slide 30 text

仕様テーマ：会員登録の実施 議論時に使用する代表シナリオ #1 すでに会員の人が図書館受付で図書館員にWeb会員ID依頼？ #2 すでに会員の人が自分でWeb上でWeb会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？ （該当住民のみ、該当住民でない場合は会員非対象とする） 検討・検証シナリオ： ・RDRA業務フロー（1段階詳細化） RDRAの情報を1段階詳細化します 紹介するフロー：新規会員登録時をして 図書館員が会員ID登録まで実施するまで 会員可能な住所 Z市＋近隣町 上記以外 バリエーション 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない Web会員ID場所（仮説込み） 図書館員が会員登録/カード作成時に仮登録？ 会員が自分でWeb上で登録

Slide 31

Slide 31 text

仕様テーマ：会員登録の実施 31 検討・検証シナリオ： 仮画面案（ペーパープロト）： 新規会員登録 Web会員ID仮登録 名前： 住所： 電話番号： 性別： 生年月日： メールアドレス： 希望ID名： （OK/登録済） 会員名： 会員カードNo：XXX Web会員ID：XXXで登録 仮パスワード：XX 登録 登録 （会員IDを登録しないで終わらせるケースはない？） 印刷 図書館システムWeb Web会員ID登録 Web会員IDを希望で設定可能とするかシンプルにカードNoにするか ※カードNoをIDにすることで制約にならないかも検討 なりすまし登録の可能性やセキュリティ問題があるのでどうするか調整 パスワード変更 登録できない住所の判別は行う →登録はZ市、近隣のAA町、BB村の3つ ※そもそも選択式で登録できないって方針もあり ＜Web会員ID登録画面＞ ＜会員登録画面＞ ＜Web会員ID情報画面＞ 図書館員用の端末 旧カードの場合どうしよう？

Slide 32

Slide 32 text

仕様テーマ：会員登録の実施 32 実現方針（案）： ・会員登録（会員カードの発行）とWeb会員ID（Webで使用可能とする）登録を分ける ・Webの画面で既会員のWeb会員ID登録を可能とする ・図書館の端末操作でも既会員のWeb会員ID登録を可能とする（会員操作と同一画面） ・図書館システムの新規会員登録に引き続きWeb会員ID登録を可能とする（双方合わせて登録でも可） 調整事項（実現に対する課題）： ・Webで新規会員登録もできる？会員登録は図書館で行ったほうがよさそう。（構築側はやりたくない） ・新システム会員に新規カード発行は必要？新規カード発行する場合、Webで登録した場合にどう渡す？ ・既存のカードを使うことができる会員は継続でよいか？（カードNoなどの継続性、Web会員IDルールも確認） ・完全新規登録の会員でWebを使わない人は放置でよい？希望なければWebアクセスできない仕組みにする？ ＜SaPIDのリスク分析より出てくるもの＞ ・Web登録のなりすまし・情報漏洩の可能性について検討、Webを使わない人への考慮も必要 →多少利便性を下げてもセキュリティを高くした方がよいのではないか？ 仕様： ・後のページより ※ここまでの情報を渡して議論して、決めた内容を仕様としてまとめる。 テンプレートタイトル 内容 実現方針 人の運用でカバーを含めての実現方法を書きます。 （調整事項） 中間ヒアリングでの質問事項。最後には消えます。

Slide 33

Slide 33 text

仕様テーマ：会員登録の実施 33 参考： ・ひとまず一式を検討し終えたタイミングでSaPIDの資料を再確認すると、 疑問に対するステークホルダ側の回答がある程度予想がつきます ・今回の場合は… - 図書館員の負担となるケースは減らす手続きを選択するだろう - セキュリティはすでにリスクでも出されているので、安全に倒したほうがよいだろう 説明補足

Slide 34

Slide 34 text

仕様テーマ：会員登録の実施 34 仕様： ・TBDなう

Slide 35

Slide 35 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ あとで書くので現状は枠のみ テスト向け

Slide 36

Slide 36 text

仕様テーマ：会員登録の実施 36 ヒアリングで得た情報： ※本内容は半分程度、墨田区図書館のシステムを参考としてます。 ＜会員ルール＞ ・既存会員も2年に1度会員更新が必要というルール→2年後には全員更新される ・既存のカードは5桁の数字、バーコード管理。会員追加のたびにインクリメントしている（図書館毎にNoを採番している） ・既存の通り図書館で新規会員登録はできるが、Webだけでも会員カード申請を行いたい（カードは図書館受取り） ・会員全員にカードおよび会員No（会員カードNo）を発行する ・既存のカードはそのまま使用可能としたい（カード廃止はしない） セルフレジもバーコード読み取りさせる <図書館横断ルール> ・現図書館（市内で4館）で個別にNo設定されている。ただし、バーコードシステム/会員Noルールは全図書館同じものを使用 ・Z市の人口が増えている＋図書館横断となるため、会員カードNoも増やす→5桁から6桁に増やす ・既存の図書館の会員Noは上位桁を0扱いとする。Web登録時には5桁の番号の場合に登録図書館名をセットで情報として使う ・新規カードNoは1XXXXX以降で採番し、市内の図書館4館共通で使えるカードにする ＜参考：スマホ向け情報＞ ・スマホでは会員カードのバーコードと同じものを表示できれば良い ＜Web会員ID登録＞ ・できれば既存のカードのままでもWeb会員ID登録をしてWebを使えるようにする ・図書館員は負担が大きいため、作業を増やさないこと→会員が自分でWeb/図書館端末で会員IDを登録する ＜セキュリティ＞ ・多少使い勝手を下げても情報漏洩が無いようにしたい ・Webでは予約・貸与中の書籍情報確認のみでもよい ・Webの会員ID登録しないでカードのみで図書館を使用する人も許容する→Webのなりすまし対策も検討 赤字は厄介そうな部分

Slide 37

Slide 37 text

仕様テーマ：会員登録の実施 37 ヒアリング前に予想されること SaPID側の情報があると、ある程度の回答が予想できる。

Slide 38

Slide 38 text

仕様化検討のケーススタディ： Vol2．ヒアリング結果から、仕様を完成させる 38 ・ヒアリング結果を活用して各種情報を更新する ・ヒアリング結果をふまえた実現方針（運用で対処を含む内容）を記載する ・具体的な仕様を描く（必要に応じて分割する） ・上記検討で、追加で確認する事項が発生した場合には再度ヒアリングを行う SaPID情報 仕様 Vol1 RDRA情報 ヒアリングのための 仮説仕様を作る ・背景 ・課題・やりたいこと ・検討・検証シナリオ ・調整事項 ヒアリング結果から 仕様を完成させる ・全体更新 ・実現方針 ・仕様 仕様 Vol2 ユーザー/顧客 ヒアリング ヒアリング 結果 仕様に対する テスト設計から フィードバックする ・テスト向け情報 ・全体更新 仕様 Vol3 必要に応じて ユーザー/顧客 との共有 テスト 設計 テスト 設計結果

Slide 39

Slide 39 text

仕様化検討のケーススタディ： Vol2．ヒアリング結果から、仕様を完成させる 39 Vo1でのヒアリング結果と それを踏まえたVol2への更新を紹介します。 具体例紹介

Slide 40

Slide 40 text

仕様の例：Vol2 ヒアリング結果から、仕様を完成へ 40

Slide 41

Slide 41 text

仕様テーマ：会員登録の実施 41 背景： ・図書館システムの導入に対して事前に会員登録を行う方針とする ・システム導入前から使用している会員および会員カードについてはそのまま使えるようにする ・Webシステムを使えるようにするために、会員にWeb会員ID（パスワードつき）を付与したい ・前提として、すでに会員カードの登録している会員がいる状況、新システムが不要な人もいる ・前提として、2年前から会員は2年に1度更新する仕組みとしている 課題・やりたいこと： ・新規登録者には番号（6桁）付きの会員カードを発行したい。既存は5桁のIDで新規システムでは一桁増やす 完全新規の場合、図書館もしくはWebで会員申請、図書館で新規会員カードの発行する ・現在の図書館IDもWebで登録可能とする。登録時に5桁のIDの場合には登録図書館名とセットで扱う。 ・すでに会員で会員カードを持っていて、Webを使わない方は元の会員カードで書籍貸与ができる ・すでに会員で会員カードを持っている人は、利用者本人がWeb画面でWeb会員ID登録ができる （新システム間相互は過去のカードを持つ人もWeb会員ID登録ができる） ・Web会員IDを登録することで、スマホ（ブラウザ/アプリ）で表示してカードの代わりに使用できる スマホで会員ID6桁およびバーコードの表示ができるようにする。最初はブラウザのみで運用 ・Web会員IDの登録をすることで、図書館横断でカードが利用できるようになる ＜別論点の課題＞ ・会員カードを忘れる人が多いので、スマホでも貸出ができる仕組みを作る（貸出処理は別仕様で整理） ・既会員で会員カードを持っている人が継続的に運用ができるようにテストで確認 ・会員情報を変更するような場合にWebから可能にする方法は別途整理する

Slide 42

Slide 42 text

仕様テーマ：会員登録の実施 42 検討・検証シナリオ： ・ステークホルダと議論をやりやすいシナリオを導出します 会員可能な住所 Z市＋近隣町 上記以外 バリエーション 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない Web会員IDの登録場所（仮説込み） 図書館員が会員登録/カード作成時に仮登録？ 会員が自分でWeb上で登録 目先で議論しやすいシナリオ（条件）を選定 表示条件整理 #1 #2 #3 会員状況 既に会員、Web会員ID登録済 対象外 - - - 既に会員、Web会員ID登録なし 対象 〇 〇 - まだ会員ではない 対象 - - 〇 会員可能な住所 Z市＋近隣町（会員対象） 対象 〇 〇 〇 上記以外（会員非対象） 画面案だけ確認 - - - Web会員ID登録場所 図書館員が仮登録？ 対象 〇 - - 会員が自分でWeb上で登録 対象 - 〇 〇 シナリオ ひとまず採用 〇 〇 〇 非採用 - - - 議論時に使用する代表シナリオ #1 すでに会員の人が図書館受付で図書館員に会員IDを登録？ #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？ （該当住民のみ、該当住民でない場合は会員非対象とする） Vol1情報

Slide 43

Slide 43 text

仕様テーマ：会員登録の実施 43 検討・検証シナリオ： ・ステークホルダと議論をやりやすいシナリオを導出します 会員可能な住所 Z市＋近隣町 上記以外 バリエーション 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない 目先で議論しやすいシナリオ（条件）を選定 議論時に使用する代表シナリオ ＜会員登録を図書館で実施するとき＞ #1 すでに会員の人が図書館受付で図書館員に会員IDを登録？ #1 すでに会員の人が図書館端末にて自分で会員IDを登録 #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？ #3 まだ会員で無く、図書館で会員登録＋Webで会員ID登録 Vol2情報 会員登録申請場所 図書館 Web Web会員IDの登録場所（仮説込み） 図書館員が会員登録/カード作成時に仮登録？ 図書館端末にて会員が自分で登録 会員が自分でWeb上で登録 条件整理 #1 #2 #3 #4 会員状況 既に会員、Web会員ID登録済 対象外 - - - - 既に会員、Web会員ID登録なし 対象 〇 〇 - - まだ会員ではない 対象 - - 〇 - 会員登録/カード作成場所 図書館 対象 〇 〇 〇 - Web（カードは図書館で受け取る） 対象 - - - 〇 会員可能な住所 Z市＋近隣町（会員対象） 対象 〇 〇 〇 - 上記以外（会員非対象） 画面案だけ確認 - - - - Web会員ID登録場所 図書館端末にて会員が登録 対象 〇 - - - 会員が自分でWeb上で登録 対象 - 〇 〇 - シナリオ ひとまず採用 〇 〇 〇 〇 非採用 - - - -

Slide 44

Slide 44 text

仕様テーマ：会員登録の実施 議論時に使用する代表シナリオ #1 すでに会員の人が図書館受付で図書館員に会員IDを登録？ #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？ （該当住民のみ、該当住民でない場合は会員非対象とする） 検討・検証シナリオ： ・RDRA業務フロー（1段階詳細化） 会員可能な住所 Z市＋近隣町 上記以外 バリエーション 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない Web会員IDの登録場所（仮説込み） 図書館員が会員登録/カード作成時に仮登録？ 会員が自分でWeb上で登録 Vol1情報 希望IDには対応しない カードNo＝アカウント カード発行 は必須 必ず会員が実施 Webか図書館端末 （カードNoが必要）

Slide 45

Slide 45 text

仕様テーマ：会員登録の実施 検討・検証シナリオ： ・RDRA業務フロー（1段階詳細化） 会員可能な住所 Z市＋近隣町 上記以外 バリエーション 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない Vol2情報 会員登録申請場所 図書館 Web Web会員IDの登録場所（仮説込み） 図書館員が会員登録/カード作成時に仮登録？ 図書館端末にて会員が自分で登録 会員が自分でWeb上で登録 議論時に使用する代表シナリオ ＜会員登録を図書館で実施するとき＞ #1 すでに会員の人が図書館受付で図書館員に会員IDを登録？ #1 すでに会員の人が図書館端末にて自分で会員IDを登録 #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？ #3 まだ会員で無く、図書館で会員登録＋Webで会員ID登録

Slide 46

Slide 46 text

仕様テーマ：会員登録の実施 検討・検証シナリオ： ・RDRA業務フロー（1段階詳細化） 会員可能な住所 Z市＋近隣町 上記以外 バリエーション 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない Vol2情報 会員登録申請場所 図書館 Web Web会員IDの登録場所（仮説込み） 図書館員が会員登録/カード作成時に仮登録？ 図書館端末にて会員が自分で登録 会員が自分でWeb上で登録 議論時に使用する代表シナリオ ＜会員登録をWebで実施するとき＞ →スコープが大きくなりすぎるので、 図書館で会員登録のケースを検討後に 議論することを合意して後回しにします。 （サンプルからは除外） 段階的な検討を合意する ただ、後回しにしても 業務フローレベルは 軽く合意しておく

Slide 47

Slide 47 text

仕様テーマ：会員登録の実施 47 （参考）： ・実際の進め方でも、検討サイズ大と判断した場合には範囲を絞り、段階的に議論することを合意します。 後回しにする場合でも、業務レベルの流れと課題だけ出して置くことを推奨します。 ※今回の例では、まず「図書館で会員登録」を検討後に「Webで会員申請」を検討することを合意します。 図書館で会員登録 できるプロトタイプ Webでも会員申請 できるシステム 仕様検討 その① （および実装） 仕様検討 その② （および実装） 最初にこちらを専念する ことを合意して進める 今回はやらず、業務の流れだけ確認。 あとで実施することを合意する 説明補足

Slide 48

Slide 48 text

図書館員用の端末 仕様テーマ：会員登録の実施 48 検討・検証シナリオ： 仮画面案（ペーパープロト）： 新規会員登録 Web会員ID仮登録 名前： 住所： 電話番号： 性別： 生年月日： メールアドレス： 希望ID名： （OK/登録済） 会員名： 会員カードNo：XXX 会員ID：XXXで登録 仮パスワード：XX 登録 登録 （会員IDを登録しないで終わらせるケースもある？） 印刷 図書館システムWeb 会員IDを希望の設定可能とするかシンプルにカードNoにするか ※カードNoをIDにすることで制約にならないかも検討 なりすまし登録の可能性やセキュリティ問題があるのでどうするか調整 パスワード変更 登録できない住所の判別は行う →登録はZ市、AA町、BB村の3つ ※そもそも選択式で登録できないって方針もあり ＜Web会員ID登録画面＞ ＜会員登録画面＞ ＜Web会員ID情報画面＞ 新システムは図書館統合なので旧カード でのWeb会員ID登録は図書館指定が必要 カードのみ発行して渡す 会員カードNoは必須 図書館員による Web会員ID仮登録は不要 Web会員ID＝カードNo （旧カードは元図書館情報込み） 個人設定は確認不可能 会員ID登録時に 生年月日と電話番号のみ を入力して照会する ※照会のみ、参照不可能 Vol1情報 Web会員ID登録

Slide 49

Slide 49 text

仕様テーマ：会員登録の実施 49 検討・検証シナリオ： めんどくさい会員IDルールの統合 ・現カードは対象図書館の判断が可能、ID5桁というのは統一、バーコードリーダーも同じものを使用。 各図書館でIDを付与しているのでIDだけを見ると重複あり、該当図書館しか使わない想定。 ・新カードは図書館統合で使用する。ID6桁とする。 現カードX Vol2情報 X町図書館 ID:12345 （みずの） 現カードY Y町図書館 ID:12345 （あだち） IDと図書館名の2つの情報で ユーザを特定 上位1桁は「0」扱い 新カード 図書館統一 ID:123456 （みずの） 6桁のID、1桁目が1以上で判断 Web会員ID のルール

Slide 50

Slide 50 text

仕様テーマ：会員登録の実施 50 検討・検証シナリオ： 仮画面案（ペーパープロト）： 新規会員登録 名前： 住所： 電話番号： 性別： 生年月日： 登録パスワード： パスワード確認： 会員カードNo： 電話番号 ： 生年月日 ： 登録 登録 （確認画面を用意） カード発行への導線も用意する （運用）カードNoの使い方、 会員IDの登録方法を伝える 確定 図書館システムWeb （図書館端末でも同じ） Web会員ID登録 登録できない住所は選択式なので入力できない →登録は登録はZ市、AA町、BB村の3つ ＜Web会員ID登録画面＞ ＜会員登録画面＞ ＜Web会員ID登録確認画面＞ Web会員ID＝カードNo （旧カードは登録図書館情報も持つ） 個人設定は確認不可能 Z市▼ 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました 会員ID登録時に 生年月日と電話番号のみを 入力して照会する ※照会のみ、保存しない キャンセル 図書館員用の端末 Vol2情報 （5桁Noのカード時） 登録図書館 ： 旧カードとのNo体系 の違いを吸収

Slide 51

Slide 51 text

仕様テーマ：会員登録の実施 51 検討・検証シナリオ： 仮構成案（ペーパープロト）： 会員登録 図書館員 ユーザー情報 ＜Webシステム＞ バーコード 会員No XXXXXX 会員 Web会員ID登録 ユーザ情報を確認 する画面はない ID登録時 照会のみ （別で検討）各種Web操作 書籍検索、予約、貸与中書籍確認、 書籍のリクエスト等ができる 申請用紙 （手書き） 電話番号と生年月日 は照会のみで データは置かない ＜図書館会員管理システム＞ 個人情報は こちらで管理 市内図書館の 統合データと なる IDの追加 スマホでカード代替（仮） メモ：Web登録なし というオプションも あったほうがよい？ Vol2情報 カード発行

Slide 52

Slide 52 text

仕様テーマ：会員登録の実施 52 検討・検証シナリオ： 仮構成案（ペーパープロト）：Web会員申請のあたりをつけると… 会員登録 図書館員 ユーザー情報 ＜Webシステム＞ バーコード 会員No XXXXXX 会員 Web会員ID登録 ID登録時 照会のみ （別で検討）各種Web操作 書籍検索、予約、貸与中書籍確認、 書籍のリクエスト等ができる 申請用紙 （手書き） ＜図書館会員管理システム＞ 個人情報は こちらで管理 市内図書館の 統合データと なる IDの追加 スマホでカード代替（仮） メモ：Web登録なし というオプションも あったほうがよい？ Vol2情報 カード発行 会員登録（カード）申請 会員申請 承認

Slide 53

Slide 53 text

仕様テーマ：会員登録の実施 53 検討・検証シナリオ（システム全体範囲）： 仮構成案（ペーパープロト）： 説明補足 重要な業務をあと2-3個議論して決めるとして、 システムの「あたり」はつけて制約を確認 特に初期はこの程度のざっくり感

Slide 54

Slide 54 text

仕様テーマ：会員登録の実施 トレードオフ テーマ：カードの更新有無 ・図書カードを全員新カードへ更新する ・旧カードを使えるようにする Vol2情報 案 懸念 コスト 課題：従業員負荷 課題：利便性 図書カードを全員 新カードへ更新する 懸念 ・図書館毎のID重複へ対応 ・Web会員IDへの複雑さと ユーザへのわかりにくさ ・カード更新時の作業量 ・新RFIDシステムとの整合性 比較的安くなる 移行もシンプル 初期運用時が大変 図書館に来る人 全員が更新になる 全員移行すれば わかりやすい 旧カードを 使えるようにする 厄介 既存カードで凌ぐ ので最初の負担が 大幅に減る Web会員の動線が 新旧カードになっ てわかりづらい （参考）：上位の検討ベースでの「あたり」のつけかた。トレードオフ、方針決定（Architecture Decision）例 その他の各テーマを挙げて同等の検討をする→各種決定の中間議論を残すと、見直しの際にも役立つ ・図書館員にてWeb仮登録を行うかどうか ・Webでの会員（カード）申請をするかどうか SaPIDの検討があれば 判断基準はだいたい見える

Slide 55

Slide 55 text

仕様テーマ：会員登録の実施 55 実現方針（案）： ・会員登録（会員カードの発行）と会員ID（Webで使用可能とする）登録を分ける ・Webの画面で既会員の会員ID登録を可能とする ・図書館の端末操作でも既会員の会員ID登録を可能とする（会員操作と同一画面） ・図書館システムの新規会員登録に引き続き会員ID登録を可能とする（双方合わせて登録でも可） 調整事項（実現に対する課題）： ・Webで完全新規登録できる？会員登録は図書館で行ったほうがよさそう。 ・新システム会員に新規カード発行は必要？新規カード発行する場合、Web登録した場合の導線はどうする？ ・既存のカードを使うことができる会員は継続放置でよいか？（カードNoなどの継続性、会員IDのルール） ・完全新規登録の会員でWebは使わない人は放置でよい？希望なければWebアクセスできない仕組みにする？ ・Web登録での、なりすまし・情報漏洩の可能性について検討、Webを使わない人への考慮も必要 ・（上記検討後）使用する画面構成について 仕様： ・後のページより ※ここまでの情報を渡して議論して、決めた内容を仕様としてまとめる。 Vol1情報

Slide 56

Slide 56 text

仕様テーマ：会員登録の実施 56 ※ひとまず、図書館での新規会員登録/カード発行を開発する。 分割テーマ： 1．新規会員登録 2．Web会員ID登録 実現方針（1．新規会員登録）： ・会員ではない人は必ず図書館で新規会員登録を行う ・（運用）会員希望者が申請用紙に記入して提出し、図書館員が登録を行う ・（運用）証明書を提出して、登録者を確認の上会員登録を行う ・会員登録情報を入力後、会員カードNo（新規は6桁）付きの会員カードを発行する ・（運用）会員IDの登録方法は、個別に新規会員に説明（説明用紙などを作成してもらう） 実現方針（2．Web会員ID登録）： ・会員カードNoを用いてWeb会員ID登録を可能とする ・既会員も既存の会員カードNoでWeb会員ID登録ができる、 ・Webの画面と図書館端末で既会員のWeb会員ID登録を可能とする（図書館端末でもWebと同一画面） ・（参考）Webシステムでは、氏名や住所などの個人情報は直接取り扱わないようにする →多少使い勝手を下げても情報漏洩が無い仕組みにする ・（参考）Webでは予約・貸与中の書籍情報確認のみでもよい ・（参考）スマホではカードの代替となる会員Noとバーコード表示ができればよい Vol2情報

Slide 57

Slide 57 text

仕様： 1．新規会員登録 ・会員登録画面を用意する 必要な情報は、下記の画面構成を参考のこと ・全体メニューから会員登録画面へ移動できる ・住所はZ市とAA町、BB村の3つのみ選択できる形式とする ・（その他入力形式のルールは省略） ・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する ・確認画面移行時に会員Noを仮採番、確認後にカード発行を可能とする ・カード発行時に会員情報を図書館会員管理システムへ追加する ・カード発行時にWebシステムへWeb会員ID（≒会員No）を追加、 会員のWeb会員IDを登録可能とする ※既存会員の移行作業が必要 仕様テーマ：会員登録の実施 57 名前： 住所： 電話番号： 性別： 生年月日： 登録 ＜会員登録画面＞ Z市▼ 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：XXX-XXXX-XXXX 性別 ：男女 生年月日 ：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ ・カード発行機でカード発行 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 キャンセル 会員No 仮採番 Vol2情報

Slide 58

Slide 58 text

登録パスワード： パスワード確認： 会員カードNo： 電話番号 ： 生年月日 ： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 仕様： 2．Web向け会員ID登録 ・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考 ・図書館の端末画面からもWeb会員ID登録画面へ移動できる ・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする図書館の選択があること - 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認） - 登録パスワードとパスワード確認が一致していること ・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる ・ Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される ・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別途検討 仕様テーマ：会員登録の実施 58 確定 ＜Web会員ID登録確認画面＞ 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました キャンセル 図書館システムWeb （図書館端末でも同じ） Web会員ID登録 Vol2情報

Slide 59

Slide 59 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ あとで書く テスト向け

Slide 60

Slide 60 text

仕様化検討のケーススタディ： Vol3．仕様に対するテスト設計からフィードバックする 60 ・仕様からテストを検討し、具体的にテストを設計する ・テストが必要以上に複雑になるような箇所や考慮したほうがよい異常ケースなどの対応がある場合、 再度ヒアリング等で確認しつつ仕様に取り込む ・業務バリエーション、業務シナリオからテストを設計し、必要に応じてフィードバックを行う SaPID情報 仕様 Vol1 RDRA情報 ヒアリングのための 仮説仕様を作る ・背景 ・課題・やりたいこと ・検討・検証シナリオ ・調整事項 ヒアリング結果から 仕様を完成させる ・全体更新 ・実現方針 ・仕様 仕様 Vol2 ユーザー/顧客 ヒアリング ヒアリング 結果 仕様に対する テスト設計から フィードバックする ・テスト向け情報 ・全体更新 仕様 Vol3 必要に応じて ユーザー/顧客 との共有 テスト 設計 テスト 設計結果

Slide 61

Slide 61 text

仕様化検討のケーススタディ： Vol3．仕様に対するテスト設計からフィードバックする 61 Vo2の結果にテスト設計を行った結果をフィードバックさせる例を紹介します。 具体例紹介

Slide 62

Slide 62 text

仕様の例：Vol3 テスト設計によりフィードバックする 62

Slide 63

Slide 63 text

仕様： 1．新規会員登録 ・会員登録画面を用意する 必要な情報は、下記の画面構成を参考のこと ・全体メニューから会員登録画面へ移動できる ・住所はZ市とAA町、BB村の3つのみ選択できる形式とする ・（その他入力形式のルールは省略） ・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する ・確認画面移行時に会員Noを仮採番、確認後にカード発行を可能とする ・カード発行時に会員情報を図書館会員管理システムへ追加する ・カード発行時にWebシステムへ会員ID（≒会員No）を追加し、 Webからの会員ID登録可能とする 仕様テーマ：会員登録の実施 63 名前： 住所： 電話番号： 性別： 生年月日： 登録 ＜会員登録画面＞ Z市▼ 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：XXX-XXXX-XXXX 性別 ：男女 生年月日 ：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ ・カード発行機でカード発行 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 キャンセル 会員No 仮採番 Vol2情報 まず、こちらの仕様に対してテストを考えてみる

Slide 64

Slide 64 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 1．新規会員登録：仕様に対するテストの全体案 テスト向け 名前： 住所： 電話番号： 性別： 生年月日： 確認 ＜会員登録画面＞ Z市▼ 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：XXX-XXXX-XXXX 性別 ：男女 生年月日 ：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ キャンセル ・カード発行機でカード発行 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 会員登録 チェック 会員No仮採番 カード期限設定 カード発行 会員情報の図書館会員 管理システムへの追加 Webシステムへの 会員ID追加 会員No 仮採番 検討の例 ・ふるまいのあたりをつける ・関連するデータを考える ・それぞれ詳細テスト設計する

Slide 65

Slide 65 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 1．新規会員登録：仕様に対するテストの全体案 テスト向け 名前： 住所： 電話番号： 性別： 生年月日： 確認 ＜会員登録画面＞ Z市▼ 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：XXX-XXXX-XXXX 性別 ：男女 生年月日 ：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ キャンセル ・カード発行機でカード発行 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 会員登録 チェック 会員No仮採番 カード期限設定 登録日 カード発行 会員情報の図書館会員 管理システムへの追加 Webシステムへの 会員ID追加 会員DB 会員DB WebDB カード発行機 会員No 仮採番 入力： 会員情報 検討の例 ・ふるまいのあたりをつける ・関連するデータを考える ・それぞれ詳細テスト設計する

Slide 66

Slide 66 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 1．新規会員登録：仕様に対するテストの全体案 テスト向け 名前： 住所： 電話番号： 性別： 生年月日： 確認 ＜会員登録画面＞ Z市▼ 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：XXX-XXXX-XXXX 性別 ：男女 生年月日 ：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ キャンセル ・カード発行機でカード発行 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 会員登録 チェック 会員No仮採番 カード期限設定 登録日 カード発行 会員情報の図書館会員 管理システムへの追加 Webシステムへの 会員ID追加 会員DB 会員DB WebDB カード発行機 会員No 仮採番 入力： 会員情報 検討の例 ・ふるまいのあたりをつける ・関連するデータを考える ・それぞれ詳細テスト設計する なんかあやしい

Slide 67

Slide 67 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 1．新規会員登録：会員No仮採番のテスト検討 テスト向け 会員登録 チェック 会員No仮採番 カード期限設定 登録日 会員情報の図書館会員 管理システムへの追加 Webシステムへの 会員ID追加 会員DB 会員DB WebDB Aさん（1人目） Bさん（2人目） Cさん（3人目） 仮採番（000001） キャンセル Time 仮採番（000002） 登録 仮採番（?） 仮採番（000003） No 状態 000001 仮採番 000002 仮採番 000003 仮採番 No 状態 000001 仮採番 000002 登録 000003 仮採番 No 状態 000001 なし 000002 登録 000003 仮採番 No 状態 000001 ？？ 000002 登録 000003 仮採番 000004 ？？ 入力： 会員情報 検討の例 ・ふるまいのあたりをつける ・関連するデータを考える ・それぞれ詳細テスト設計する 仮採番、 キツくない？

Slide 68

Slide 68 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 1．新規会員登録：仕様に対するテストの全体案 テスト向け 名前： 住所： 電話番号： 性別： 生年月日： 確認 ＜会員登録画面＞ Z市▼ 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：XXX-XXXX-XXXX 性別 ：男女 生年月日 ：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ キャンセル ・カード発行機でカード発行 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 入力： 会員情報 会員登録 チェック 会員No仮採番 カード期限設定 登録日 カード発行 会員情報の図書館会員 管理システムへの追加 Webシステムへの 会員ID追加 会員DB 会員DB WebDB カード発行機 会員No 仮採番 仮採番は仕様として キツイ カード発行は失敗ケース を最初から考慮

Slide 69

Slide 69 text

仕様（Vol2）： 1．新規会員登録 ・会員登録画面を用意する 必要な情報は、下記の画面構成を参考のこと ・全体メニューから会員登録画面へ移動できる ・住所はZ市とAA町、BB村の3つのみ選択できる形式とする ・（その他入力形式のルールは省略） ・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する ・確認画面移行時に会員Noを仮採番し、確認後にカード発行を可能とする ・カード発行時に会員情報を図書館会員管理システムへ追加する ・カード発行時にWebシステムへ会員ID（≒会員No）を追加し、 Webからの会員ID登録可能とする 仕様テーマ：会員登録の実施 69 名前： 住所： 電話番号： 性別： 生年月日： 確認 ＜会員登録画面＞ Z市▼ 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：XXX-XXXX-XXXX 性別 ：男女 生年月日 ：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ キャンセル ・カード発行機でカード発行 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 会員No 仮採番

Slide 70

Slide 70 text

仕様（Vol3）：テスト設計での見直し結果 1．新規会員登録 ・会員登録画面を用意する 必要な情報は、下記の画面構成を参考のこと ・全体メニューから会員登録画面へ移動できる ・住所はZ市とAA町、BB村の3つのみ選択できる形式とする ・電話番号は半角数字のみでハイフンなし入力とする、生年月日は選択形式 ・（その他入力形式のルールは省略） ・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する ・確認画面で、確認後に会員No採番とカード発行を可能とする ・カード発行時に会員情報を図書館会員管理システムへ追加する ・カード発行時にWebシステムへ会員ID（≒会員No）を追加し、 Webからの会員ID登録可能とする ・カード発行失敗時のために再発行操作を可能とする 仕様テーマ：会員登録の実施 70 名前： 住所： 電話番号：半角数字 性別： 生年月日：選択 確認 ＜会員登録画面＞ Z市▼ 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：0123456789 性別 ：男女 生年月日 ：XXXX/XX/XX 会員No ：123456 カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ キャンセル 会員No 採番 ・カード発行機でカード発行 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 会員カードを発行しました Webシステムへ登録しました 会員No123456 カード再発行 終了

Slide 71

Slide 71 text

登録パスワード： パスワード確認： 会員カードNo： 電話番号 ： 生年月日 ： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 仕様： 2．Web向け会員ID登録 ・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考 ・図書館の端末画面からもWeb会員ID登録画面へ移動できる ・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする登録図書館が選択されていること - 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認） - 登録パスワードとパスワード確認が一致していること ・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる ・ Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される ・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別途検討 仕様テーマ：会員登録の実施（Vol2） 71 確定 ＜Web会員ID登録確認画面＞ 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました キャンセル 図書館システムWeb （図書館端末でも同じ） Web会員ID登録 Vol2情報 こちらも仕様に対してテストを考えてみる

Slide 72

Slide 72 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録： 仕様に対するテストの全体案 テスト向け 図書館システムWeb （図書館端末でも同じ） 会員ID登録 会員ID登録チェック 新旧カード 会員No確認 会員照会 期限確認 会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの 会員・パスワード登録 WebDB ※その他初期データ作成時は確認 登録パスワード： パスワード確認： 会員カードNo： 電話番号 ： 生年月日 ： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 確定 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました キャンセル ＜Web会員ID登録確認画面＞

Slide 73

Slide 73 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録： 仕様に対するテストの全体案 テスト向け 図書館システムWeb （図書館端末でも同じ） 会員ID登録 会員ID登録チェック 会員照会 期限確認 会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの 会員・パスワード登録 WebDB ※その他初期データ作成時は確認 UIだけからは発想しづらいが、 会員期限もチェックが必要 登録パスワード： パスワード確認： 会員カードNo： 電話番号 ： 生年月日 ： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 確定 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました キャンセル ＜Web会員ID登録確認画面＞ 新旧カード 会員No確認

Slide 74

Slide 74 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録： 仕様に対するテストの全体案 テスト向け 確定 キャンセル 図書館システムWeb （図書館端末でも同じ） 会員ID登録 会員ID登録チェック 会員ID確認 会員照会 期限確認 会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの 会員・パスワード登録 WebDB ※その他初期データ作成時は確認 会員ID登録時には 期限の確認も必要 会員DB側への照会を考慮すると フロントでの入力制約もあるとよい （半角しばり、ハイフン無しなど） 登録パスワード： パスワード確認： 会員カードNo： 電話番号 ： 生年月日 ： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました ＜Web会員ID登録確認画面＞

Slide 75

Slide 75 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：Web会員ID登録チェックのCFD（Cause Flow Diagram）テスト設計 テスト向け 会員No確認（WebDB） 会員カードNo登録済 入力NG 通知 新旧カード 会員No確認 会員照会 期限確認 会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの 会員・パスワード登録 WebDB ※その他初期データ作成時は確認 会員カードNoがない 会員照合（会員DB） 入力の不正値 カードNo、電話番号、 生年月日不整合 カード期限確認 カード期限内 カード期限切れ 会員期限 NG通知 カードNo、電話番号、 生年月日が整合 入力パスワード確認 登録OK 確認画面 へ 入力の不正値 登録内容と確認内容 が異なる 登録内容と確認内容 が整合 Password NG通知 NG通知の適切さも 議論することが可能 照合対象データの形式 をここで検討できる 新旧カード確認 入力の不正値 カード情報 NG通知 新旧カード併用の わかりづらい点を 通知でフォロー 新カードの6桁No 旧カードの5桁No ＆ 登録図書館の入力

Slide 76

Slide 76 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 新旧カードのわかりづらさを改善調整 テスト向け 新旧カード確認 新カードの6桁No 入力の不正値 旧カードの5桁No ＆ 登録図書館の入力 カード情報 NG通知 新旧カード併用の わかりづらい点を 通知でフォロー？ 登録パスワード： パスワード確認： 会員カードNo： 電話番号 ： 生年月日 ： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 登録パスワード： パスワード確認： （6桁Noのカード時） 会員カードNo： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 会員カードNo： OR 電話番号 ： 生年月日 ： ？ そもそもの 仕組み上の複雑さ をカバーする デザインも必要 ※雑ですが ？ 画面上の説明、ヘルプ 入力チェックや エラーメッセージの 工夫が必要な箇所を特定 Noの入力フィールド 1つで5桁6桁判断？ ＋登録図書入力判断？

Slide 77

Slide 77 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：会員ID登録チェックのCFD （Cause Flow Diagram）テスト設計 テスト向け

Slide 78

Slide 78 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：会員ID登録チェックのCFDテスト設計 ※CFDから生成したデシジョンテーブル テスト向け Enterprise Architect＋CFDアドインを使用 ツールの活用でDTまで作成も可能

Slide 79

Slide 79 text

登録パスワード： パスワード確認： 会員カードNo： 電話番号 ： 生年月日 ： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 仕様（Vol2）： 2．Web向け会員ID登録 ・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考 ・図書館の端末画面からもWeb会員ID登録画面へ移動できる ・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする登録図書館が選択されていること - 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認） - 登録パスワードとパスワード確認が一致していること ・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる ・ Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される ・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別論点 仕様テーマ：会員登録の実施 79 確定 ＜Web会員ID登録確認画面＞ 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました キャンセル 図書館システムWeb （図書館端末でも同じ） Web会員ID登録

Slide 80

Slide 80 text

仕様（Vol3）：テスト設計での見直し結果 2．Web向け会員ID登録 ・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考 ・図書館の端末画面からもWeb会員ID登録画面へ移動できる。Web会員登録画面ではヘルプを用意する ・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする登録図書館が選択されていること - 会員カードNo（5桁の場合、登録図書館との組合せ）が登録していること、カード期限が有効であること - 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認） 会員カードNo、電話番号は半角数字のみでハイフンなし入力とする、生年月日は選択形式 - 登録パスワードとパスワード確認が一致していること ・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる ・Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される ・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別論点 仕様テーマ：会員登録の実施 80 確定 ＜Web会員ID登録確認画面＞ 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました キャンセル 図書館システムWeb （図書館端末でも同じ） Web会員ID登録 登録パスワード： パスワード確認： （6桁Noのカード時） 会員カードNo： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 会員カードNo： 電話番号 ： 生年月日 ： ？ ？ 半角 半角 選択 半角 選択

Slide 81

Slide 81 text

仕様テーマ：会員登録の実施 ＜テスト向け情報（全体検討）＞ テスト全体の検討例（少し俯瞰して考える） A) 仕様に対するテスト 1．新規会員登録 2． Web向け会員ID登録 B) 業務フロー、シナリオに対するテスト 以下業務バリエーションを考慮したテスト テスト向け 会員可能な住所 Z市＋近隣町 上記以外 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない 会員登録/カード作成場所 図書館 Web（将来検討） Web会員IDの登録場所 図書館端末にて会員が自分で登録 会員が自分でWeb上で登録

Slide 82

Slide 82 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ B) 業務フロー、シナリオに対するテスト 業務バリエーションを考慮したテスト：以下シナリオをベースにテストをする ・会員対象ではない人が会員登録せず/できずに帰っていただくケース（システム対象外） ・既に会員の人がWeb会員IDを登録する（PC） ・既に会員の人がWeb会員IDを登録する（スマホ） ・新規会員登録後、図書館で登録する（図書館端末） ・新規会員登録後、Web登録なしでカードのみで運用 テスト向け フィードバック ・職員の手間削減で手順1つ渡して済ませたい ・PCと図書館端末のUIを一致させるのを推奨 ・PCとスマホ双方のWeb会員ID登録手順が欲しい 会員可能な住所 Z市＋近隣町 上記以外 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない 会員登録/カード作成場所 図書館 Web（将来検討） Web会員IDの登録場所 図書館端末にて会員が自分で登録 会員が自分でWeb上で登録 →PCとスマホからの登録を想定 シナリオを テストで再検討し て活用する

Slide 83

Slide 83 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ B) 業務フロー、シナリオに対するテスト 業務バリエーションを考慮したテスト：以下シナリオをベースにテストをする ・会員対象ではない人が会員登録せず/できずに帰っていただくケース（システム対象外） ・既に会員の人がWeb会員IDを登録する（PC） ・既に会員の人がWeb会員IDを登録する（スマホ） ・新規会員登録後、図書館で登録する（図書館端末） ・新規会員登録後、Web登録なしでカードのみで運用 テスト向け フィードバック ・職員の手間削減で手順1つ渡して済ませたい ・PCと図書館端末のUIを一致させるのを推奨 ・PCとスマホ双方のWeb会員ID登録手順が欲しい 会員可能な住所 Z市＋近隣町 上記以外 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない 会員登録/カード作成場所 図書館 Web（将来検討） Web会員IDの登録場所 図書館端末にて会員が自分で登録 会員が自分でWeb上で登録 →PCとスマホからの登録を想定 運用を考慮したフィードバック例 会員ID登録の手順はA4用紙1枚程度にまとめる ＋Webとスマホ双方の手順があるとよい

Slide 84

Slide 84 text

仕様テーマ：会員登録の実施 参考： ・テストを検討する際には一度SaPID/RDRAを含めて全体の情報を見直してテストを考えることで、 検討で抜けている仕様や必要なサービスや運用補足用にやる必要があるタスクなりが見えてきます。 説明補足 84 84 窓口 会員 期限管理 会員登録 [会員管理：業務] 会員カード を作成する 図書 館員 Web会員ID を発行する 会員 [会員登録：BUC] 会員 会員登録 会員登録 条件 会員 登録 会員登録

Slide 85

Slide 85 text

まとめ：今回の流れ 今回の進め方の参考 目的を特定する 主要なシナリオ を特定する アプリケーション の全体像を描く 主要な課題を 特定する 解決策の候補 を出す Vol1/2で具体的な イメージを描きながら 特定していく ペーパープロトタイプで課題に つながる部分を描いて呼び水とする 段階的に具体的な内容を描く 課題の共有、トレードオフのため にいくつか方法を用意して 議論をすると意見が出やすい 上位の要件や情報が存在しない場合は 安達さん神崎さんのお話を聞きましょう 85 RDRAで範囲を絞り込んだうえで 業務に対するバリエーションを考慮しつつ シナリオを詳細化する

Slide 86

Slide 86 text

まとめ：今回の流れ 今回の進め方の参考→とある書籍とは「実践ソフトウェアエンジニアリング（第9版）」でした。 第4 章 推奨のプロセスモデル の内容です。 86

Slide 87

Slide 87 text

まとめ：今回の流れ 第4 章 推奨のプロセスモデル は結構面白いので興味があれば立ち読みでもしてください。 87 プロジェ クト構想 要求エンジ ニアリング 初期アーキテ クチャ設計 プロジェクト リソース見積り 1stプロトタイプ 構築 プロトタイプ 評価 継続可否判断 Go/No Go決定 プロジェ クト終了 システムの 洗練 プロトタイプ リリース ソフトウェア メンテナンス スコープ 再定義 次のプロトタ イプ構築 1stプロトタイプの構築 プロトタイプ評価と Go/No Go決定 システムのリリース、 次のプロトタイプ構築 注：こちらは、実践ソフトウェア エンジニアリング（第9版） 第4章 推奨のプロセスの説明に 独自解釈を加えたものです

Slide 88

Slide 88 text

まとめ：今回行った段階（イテレーション）と進み方 ユーザー側、開発側ともに「確信度」を高める進め方を行ってます。 ※今回は一例につき、繰り返し検討を続けるケースもあります。 開発者 確信度 ユーザー 確信度 Vol1 Vol2 Vol3 88 プロトタイピング な仕様 開発者 ユーザー 運用 実現

Slide 89

Slide 89 text

まとめ：今回行った段階（イテレーション）と進み方 ユーザー側、開発側ともに「確信度」を高める進め方を行ってます。 ※今回は一例につき、繰り返し検討を続けるケースもあります。 オレンジのように進む場合もあります… 開発者 確信度 ユーザー 確信度 Vol1 Vol2 Vol3 89 プロトタイピング な仕様 開発者 ユーザー 運用 実現

Slide 90

Slide 90 text

まとめ：最終的な仕様 最終的な仕様はいわゆる「INVEST」を達成しやすい内容となっております。 ※半分くらいはSaPIDやRDRAがあることによって達成しやすくなります。 Ⅰ：Independent 独立している RDRAにより業務としての分割がされ、仕様を検討する際に システムを考慮することで独立性が確保しやすくなります。 （RDRAにおける影響分析の技術を使うこともあります） Ｎ：Negotiable 交渉可能である ユーザー側にヒアリングした結果がすべて入ってます。 「実現方針」に運用対処の範囲を含め調整結果をまとめます。 Ｖ：Valuable 価値がある SaPIDやRDRAの検討＋「背景」や「課題・やりたいこと」 を明記して確認することで、無意味な開発は減ります。 Ｅ：Estimable 見積可能である 仕様としてまとめつつ、テーマを分割することで 個々の仕様単位でユーザーストーリー化し見積りできます。 Ｓ：Small 小さい 仕様としてまとめつつ、テーマを分割および仕様の検討段階 を分割することで、適度なサイズにすることが可能です。 Ｔ：Testable テスト可能である 「テスト向け情報」を作るプロセスが入ってます。また、 「検討・検証シナリオ」も最後にテスト向け情報になります。 90

Slide 91

Slide 91 text

まとめ：いわゆるプロダクトバックログとの関連性 アジャイル風の開発としてのプロダクトバックログとの関連性としては、 だいたい「エピック→（仕様化検討）→プロダクトバックログ」という感じの運用になります。 今回の仕様に対する各概念およびプロダクトバックログの構成の例を以下に紹介します。 ※（当然ですが）必要に応じてスプリントバックログはさらに分割して作業します。 91 プロトタイピングな仕様 1．新規会員登録 2．Web向け会員ID登録 【エピック】 会員登録を 可能とする 【PBI】 新規会員登録 （仕様参照） 【PBI】 Web向け 会員ID登録 （仕様参照） 仕様化 検討 仕様内容と分割可能かを考慮して プロダクトバックログアイテム（PBI） 単位に分けておきます

Slide 92

Slide 92 text

まとめ：（参考）仕様に対するレビュー観点、チェックリスト 開発者側は「仕様」「テスト向け情報」だけ見れば開発ができるようになる方が理想です。 仕様を記述する際には、以下のような項目でチェックすることが可能です。 前提：仕様ドキュメントのテンプレートにて事前検討をしたうえで仕様をまとめている。 ――――――――――――――――――――――――――――――――――――――――――――――――― チェックリスト/レビュー観点： □ 箇条書き単位で、1つずつふるまいを表現できている ふるまいを考慮した設計もしくはテスト検討があると分割整理とレビューがやりやすくなります □ ロジック（ビジネスルール）がある場合には、デシジョンテーブルやCFD、CEGなどを用いて表現している □（できれば）各箇条書きがテストケースと対応できる単位になっている □ 必要に応じてデータ構造がクラス図や開発者が分かる絵、リストなどで表現できている ――――――――――――――――――――――――――――――――――――――――――――――――― ※処理分割や細かいデータ構造は開発側で決めたほうがよいケースも多く、詳細さはチームにより変わります。 ロジックまでデシジョンテーブルやCFDで明確にしたうえで詳細は開発者に任せることも多数あります。 92

Slide 93

Slide 93 text

まとめ：実際の進め方 パイプライン的に仕様→実装につないで開発を進めていきます。 場合によっては開発結果をプロトタイプと捉えて、実データを登録して業務の妥当性を確認します。 要件定義 開発 フィード バック 業務①：会員登録 業務②：貸し出し 業務③：Web会員申請 プロトタイプに 会員登録のデータを登録し 業務の流れを評価 ※アジャイルを考慮した開発の流れの例 仕様化 RDRA要件定義の整理 必要に応じて更新 業務①：会員登録 実装・テスト 業務②：貸し出し 実装・テスト 必要に応じてフィードバック フィードバック フィードバック 93 フレームワーク選定や全体の課題検討 SaPIDによる価値分析 価値分析 状況によりフィードバック

Slide 94

Slide 94 text

注意事項：ペーパープロトタイピングにおける限界点と注意点 限界点 ・「現状からの変化」および「目先の変化」までがペーパープロトタイプでやりやすい範囲です。 ・逆に「今までなかったもの」はペーパープロトタイプより、動くプロトタイプを推奨します。 ・一度動くプロトタイプを作ったうえで、目先の改善検討はペーパープロトタイプで議論はやりやすいです。 ・ペーパープロトタイプは、1つの論点に対する「目先の変化」までの議論までは向いてますが、 例えば「修正後を見据えた追加改善案」までは議論がやりづらいです。 →今回の例では、「会員登録の検討結果を考慮して会員検索の仕組みを考える」というような範囲。 ・1つ先の修正が決まり次第システムを構築・修正し、評価しながら次を考えるという進め方を推奨します。 注意点 ・ペーパープロトタイプは、論点単位で議論しやすいイテレーティブなプロセスを作って活用ください。 ・説明する人によってはノイズとなりそうな意見が多くなりすぎて、逆に進まなくなるケースがあります。 →適切に論点を分けて仕分けをするファシリテーション、論理思考の技術も必要になります。 開発 仕様化 会員登録：仕様 会員登録：開発 会員検索照会： 仕様 会員Web登録： 仕様 貸し出し：開発 評価 評価 貸し出し：仕様 ・・・ 94

Slide 95

Slide 95 text

まとめ：上位のテスト 参考：SaPID/RDRAからのテスト 今回のようなSaPIDやRDRAの情報がある際には以下のように役立てることができます ・（中間で紹介しているように）テスト検討のタイミングで内容を見直すことで 俯瞰的なテスト計画/テスト（スイートアーキテクチャ？）設計において検討が抜けていないかに気づく。 ＜SaPID成果物の活用＞ ・SaPIDの成果物を用いて、テスト観点を導出する →例えば、パフォーマンスが必要な点、セキュリティの重要性などが導出できる ・ SaPIDの成果物を用いて、テスト結果の十分性を判断する →シナリオとして「図書館員の負担が減りそうか？」という判断で妥当性の判断ができるようになる ＜RDRA成果物の活用＞ ・RDRAの成果物の業務構成をテスト全体の設計構造と同一にする →RDRAの成果物は業務単位での適切な分割がやりやすく、テスト構造と一致させても使うことができる ・RDRAの成果物から業務の典型的シナリオを導出してリグレッションテストなどに活用する →紹介した仕様化方法だけでは「業務単位」のテストが導出されるので、全体を考慮したテスト検討が役立つ ・RDRAの成果物モデルとテストのトレーサビリティが取れるようにモデル化・ツール連携する →例えばEnterprise Architectを用いてモデル化し、TestRailといったテストツール構造とリンクします 95

Slide 96

Slide 96 text

まとめ：テスト担当者の出番 テスト担当者は以下のような箇所でスキルが役立つはずです。 ・業務バリエーションと業務シナリオを整理及び提案する ・仕様に対するテスト設計をして仕様へのフィードバックをする （仕様がいったん完了後にテスト設計の時間を作る、もしくは並列で進める） ・SaPIDやRDRA成果物から開発側が忘れてそうな観点（セキュリティやパフォーマンス等）を提案する 96

Slide 97

Slide 97 text

参考：使用している技術の参考文献 ■関連資料 ・RDRA+プロトタイピングおよび仕様化時に役立つ技術、事例紹介 https://www.slideshare.net/NoriyukiMizuno/rdra-236183496 ・伝統的食品工場エンジニアリング会社が挑むDXへのビジネスアイデアを RDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義 https://www.slideshare.net/NoriyukiMizuno/dxrdraside ■プロトタイピング関連 ・書籍：デザイナーのためのプロトタイピング入門 ■PSFit関連技術（仕様テンプレートの前半に対応） ・書籍：正しいものを正しく作る ■流れとプロセス/ソフトウェアエンジニアリング ・書籍：実践ソフトウェアエンジニアリング（第9版） ■CFD（Cause Flow Diagram）およびデシジョンテーブル ・書籍：ソフトウェアテスト技法ドリル ・CFDツール（EAアドイン）：https://www.sparxsystems.jp/products/EA/tech/CFD.htm ・CFD紹介： https://softest.jp/?p=100 ■図書館情報の参考 ・墨田区立図書館： https://www.library.sumida.tokyo.jp/ 97

Slide 98

Slide 98 text

おまけ：最終的な仕様 ※テスト込みで14P程度 98 最終的にはこの程度でまとめますが、 中間での議論が大量に前段階で存在します

Slide 99

Slide 99 text

仕様テーマ：会員登録の実施 99 背景： ・図書館システムの導入に対して事前に会員登録を行う方針とする ・システム導入前から使用している会員および会員カードについてはそのまま使えるようにする ・Webシステムを使えるようにするために、会員にWeb会員ID（パスワードつき）を付与したい ・前提として、すでに会員カードの登録している会員がいる状況、新システムが不要な人もいる ・前提として、2年前から会員は2年に1度更新する仕組みとしている 課題・やりたいこと： ・新規登録者には番号（6桁）付きの会員カードを発行したい。既存は5桁のIDで新規システムでは一桁増やす 完全新規の場合、図書館もしくはWebで会員申請、図書館で新規会員カードの発行する ・現在の図書館IDもWebで登録可能とする。登録時に5桁のIDの場合には登録図書館名とセットで扱う。 ・すでに会員で会員カードを持っていて、Webを使わない方は元の会員カードで書籍貸与ができる ・すでに会員で会員カードを持っている人は、利用者本人がWeb画面でWeb会員ID登録ができる （新システム間相互は過去のカードを持つ人もWeb会員ID登録ができる） ・Web会員IDを登録することで、スマホ（ブラウザ/アプリ）で表示してカードの代わりに使用できる スマホで会員ID6桁およびバーコードの表示ができるようにする。最初はブラウザのみで運用 ・Web会員IDの登録をすることで、図書館横断でカードが利用できるようになる ＜別論点の課題＞ ・会員カードを忘れる人が多いので、スマホでも貸出ができる仕組みを作る（貸出処理は別仕様で整理） ・既会員で会員カードを持っている人が継続的に運用ができるようにテストで確認 ・会員情報を変更するような場合にWebから可能にする方法は別途整理する

Slide 100

Slide 100 text

仕様テーマ：会員登録の実施 検討・検証シナリオ： ・RDRA業務フロー（1段階詳細化） 会員可能な住所 Z市＋近隣町 上記以外 バリエーション 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない 会員登録申請場所 図書館 Web（将来検討） Web会員ID場所 図書館端末にて会員が自分で登録 会員が自分でWeb上で登録 テストに使用する代表シナリオ ＜会員登録を図書館で実施するとき＞ #1 すでに会員の人が図書館端末にて自分で会員IDを登録 #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＋Webで会員ID登録 Web登録は 将来のイテレーション で検討 シナリオは テストで再活用

Slide 101

Slide 101 text

仕様テーマ：会員登録の実施 101 検討・検証シナリオ： 仮画面案（ペーパープロト）： 新規会員登録 名前： 住所： 電話番号： 性別： 生年月日： 登録 （確認画面を用意） カード発行への導線も用意する （運用）カードNoの使い方、 会員IDの登録方法を伝える 確定 図書館システムWeb （図書館端末でも同じ） 会員ID登録 登録できない住所は選択式なので入力できない →登録は登録はZ市、AA町、BB村の3つ ＜会員登録画面＞ ＜Web会員ID登録確認画面＞ Web会員IDはカードNo ログイン時に5桁IDの場合に 登録図書館も入力すること 個人設定は確認不可能 Z市▼ ＜Web会員ID登録完了＞ 登録を完了しました Web会員ID登録時に 生年月日と電話番号のみを 使用してして照会する ※照会のみ、保存しない キャンセル 図書館員用の端末 登録パスワード： パスワード確認： （6桁Noのカード時） 会員カードNo： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 会員カードNo： 電話番号 ： 生年月日 ： ？ ？ 登録図書館：XXX 会員カードNo：XXX 登録しますか？

Slide 102

Slide 102 text

仕様テーマ：会員登録の実施 102 検討・検証シナリオ： 仮構成案（ペーパープロト）： 会員登録 図書館員 ユーザー情報 ＜Webシステム＞ バーコード 会員No XXXXXX 会員期限 2023/03/15 会員 会員ID登録 ユーザ情報を確認 する画面はない ID登録時 照会のみ （別で検討）Web予約、 貸与中書籍の確認ができる 申請用紙 （手書き） 電話番号と生年月日 も照会のみで データは置かない ＜図書館会員管理システム＞ 個人情報は こちらで管理 IDの追加 スマホでカード代替（仮） メモ：Web登録なし というオプションも あったほうがよい？ →開発中追加も可能

Slide 103

Slide 103 text

仕様テーマ：会員登録の実施 103 ※ひとまず、図書館での新規会員登録/カード発行を開発する。 分割テーマ： 1．新規会員登録 2．Web向け会員ID登録 実現方針（1．新規会員登録）： ・会員ではない人は必ず図書館で新規会員登録を行う ・（運用）会員希望者が申請用紙に記入して提出し、図書館員が登録を行う ・（運用）証明書を提出して、登録者を確認の上会員登録を行う ・会員登録情報を入力後、会員カードNo（新規は6桁）付きの会員カードを発行する ・（運用）会員IDの登録方法は、個別に新規会員に説明（説明用紙などを作成してもらう） 実現方針（2．Web向け会員ID登録）： ・会員カードNoを用いてWeb会員ID登録を可能とする ・既会員も既存の会員カードNoでWeb会員ID登録ができる。この場合、登録図書館情報を使用する ・Webの画面と図書館端末でも既会員のWeb会員ID登録を可能とする（図書館端末もWebと同一画面） ・（参考）Webシステムでは、氏名や住所などの個人情報は取り扱わないようにする →多少使い勝手を下げても情報漏洩が無い仕組みにする ・（参考）Webでは予約・貸与中の書籍情報確認のみでもよい ・（参考）スマホではカードの代替となる会員Noとバーコード表示ができればよい

Slide 104

Slide 104 text

仕様： 1．新規会員登録 ・会員登録画面を用意する 必要な情報は、下記の画面構成を参考のこと ・全体メニューから会員登録画面へ移動できる ・住所はZ市とAA町、BB村の3つのみ選択できる形式とする ・電話番号は半角数字のみでハイフンなし入力とする、生年月日は選択形式 ・（その他入力形式のルールは省略） ・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する ・確認画面で、確認後に会員No採番とカード発行を可能とする ・カード発行時に会員情報を図書館会員管理システムへ追加する ・カード発行時にWebシステムへ会員ID（≒会員No）を追加し、 Webからの会員ID登録可能とする ・カード発行失敗時のために再発行操作を可能とする 仕様テーマ：会員登録の実施 104 名前： 住所： 電話番号：半角数字 性別： 生年月日：選択 確認 ＜会員登録画面＞ Z市▼ 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：0123456789 性別 ：男女 生年月日 ：XXXX/XX/XX カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ キャンセル 会員No 採番 ・カード発行機でカード発行 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 会員カードを発行しました Webシステムへ登録しました 会員No123456 カード再発行 終了

Slide 105

Slide 105 text

仕様： 2．Web向け会員ID登録 ・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考 ・図書館の端末画面からもWeb会員ID登録画面へ移動できる。Web会員登録画面ではヘルプを用意する ・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする登録図書館が選択されていること - 会員カードNo（5桁の場合、登録図書館との組合せ）が登録していること、カード期限が有効であること - 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認） 会員カードNo、電話番号は半角数字のみでハイフンなし入力とする、生年月日は選択形式 - 登録パスワードとパスワード確認が一致していること ・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる ・Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される ・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別論点 仕様テーマ：会員登録の実施 105 確定 ＜Web会員ID登録確認画面＞ 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました キャンセル 図書館システムWeb （図書館端末でも同じ） Web会員ID登録 登録パスワード： パスワード確認： （6桁Noのカード時） 会員カードNo： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 会員カードNo： 電話番号 ： 生年月日 ： ？ ？ 半角 半角 選択 半角 選択

Slide 106

Slide 106 text

仕様テーマ：会員登録の実施 ＜テスト向け情報（全体検討）＞ テスト全体 A) 仕様に対するテスト 1．新規会員登録 2．Web向け会員ID登録 B) 業務フロー、シナリオに対するテスト 以下業務バリエーションを考慮したテスト テスト向け 会員可能な住所 Z市＋近隣町 上記以外 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない 会員登録申請場所 図書館 Web（将来検討） Web会員ID場所 図書館端末にて会員が自分で登録 会員が自分でWeb上で登録

Slide 107

Slide 107 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 1．新規会員登録：仕様に対するテストの全体案 テスト向け 名前 ：XX XXX 住所 ：Z市XXX 電話番号 ：0123456789 性別 ：男女 生年月日 ：XXXX/XX/XX カード期限：2023/03/15 カード発行 ＜会員登録確認・ カード発行画面＞ 新規会員登録 ＜全体メニュー＞ ・・・ キャンセル ・会員No採番 ・図書館会員管理システムへ 会員情報を追加 ・Webシステムへ会員ID追加 ・カード発行機でカード発行 会員登録 チェック カード期限設定 登録日 カード発行 会員No採番 会員情報の図書館会員 管理システムへの追加 Webシステムへの 会員ID追加 会員DB WebDB カード発行機 入力： 会員情報 名前： 住所： 電話番号：半角数字 性別： 生年月日：選択 確認 ＜会員登録画面＞ Z市▼

Slide 108

Slide 108 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録： 仕様に対するテスト全体案 テスト向け 図書館システムWeb （図書館端末でも同じ） 会員ID登録 Web会員ID登録画面チェック 新旧カード 会員No確認 会員照会 期限確認 会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの 会員・パスワード登録 WebDB ※その他初期データ作成時は確認 確定 登録図書館：XXX 会員カードNo：XXX 登録しますか？ ＜Web会員ID登録完了＞ 登録を完了しました キャンセル ＜Web会員ID登録確認画面＞ 登録パスワード： パスワード確認： （6桁Noのカード時） 会員カードNo： 登録 ＜Web会員ID登録画面＞ （5桁Noのカード時） 登録図書館 ： 会員カードNo： 電話番号 ： 生年月日 ： ？ ？

Slide 109

Slide 109 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：Web会員ID登録チェックのCFD（Cause Flow Diagram）テスト設計 テスト向け 会員No確認（WebDB） 会員カードNo登録済 入力NG 通知 新旧カード 会員No確認 会員照会 期限確認 会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの 会員・パスワード登録 WebDB ※その他初期データ作成時は確認 会員カードNoがない 会員照合（会員DB） 入力の不正値 カードNo、電話番号、 生年月日不整合 カード期限確認 カード期限内 カード期限切れ 会員期限 NG通知 カードNo、電話番号、 生年月日が整合 入力パスワード確認 登録OK 確認画面 へ 入力の不正値 登録内容と確認内容 が異なる 登録内容と確認内容 が整合 Password NG通知 NG通知の適切さも 議論することが可能 照合対象データの形式 をここで検討できる 新旧カード確認 入力の不正値 カード情報 NG通知 新旧カード併用の わかりづらい点を 通知でフォロー 新カードの6桁No 旧カードの5桁No ＆ 登録図書館の入力

Slide 110

Slide 110 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：会員ID登録チェックのCFD （Cause Flow Diagram）テスト設計 テスト向け

Slide 111

Slide 111 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：会員ID登録チェックのCFDテスト設計 ※CFDから生成したデシジョンテーブル テスト向け Enterprise Architect＋CFDアドインを使用 ツールの活用でDTまで作成も可能

Slide 112

Slide 112 text

仕様テーマ：会員登録の実施 ＜テスト向け情報＞ B) 業務フロー、シナリオに対するテスト 業務バリエーションを考慮したテスト：以下シナリオをベースにテストをする ・会員対象ではない人が会員登録せずに帰っていただくケース（システム対象外） ・既に会員の人が会員IDを登録する（PC） ・既に会員の人が会員IDを登録する（スマホ） ・新規会員登録後、会員IDをすぐに登録する（図書館端末） ・新規会員登録後、Web登録なしでカードのみで運用 テスト向け フィードバック ・職員の手間削減で手順1つ渡して済ませたい ・PCと図書館端末のUIを一致させるのを推奨 ・PCとスマホ双方の会員ID登録手順が欲しい 会員可能な住所 Z市＋近隣町 上記以外 会員状況 既に会員、Web会員ID登録済 既に会員、Web会員ID登録なし まだ会員ではない 会員登録/カード作成場所 図書館 Web（将来検討） Web会員ID場所 図書館端末にて会員が自分で登録 会員が自分でWeb上で登録 →PCとスマホからの登録を想定

Slide 113

Slide 113 text

おしまい！