1-1システム要件定義
10月の朝、焼き上がったメロンパンを棚に並べながら、店長がぽつりと言いました。「焼きたてを待っている人に、焼けたよって知らせられたらいいのにね」。その日の午後、ミナトはさっそくノートパソコンを開き、「焼き上がりました」と出る画面を作り始めます。手を止めさせたのは相棒でした。「誰に、いつ、何を知らせるのか、まだ一つも決まっていませんね」。次の日、店長とミナトは常連さんに話を聞いてみました。「朝7時台の通知は要らないな、まだ寝てるから」「焼き上がりより、売り切れたかどうかを知りたい」。店長も考えていなかった注文が、次々に出てきます。作るのは小さな開発会社に頼むことになりましたが、店長の頭の中にある「知らせたい」を、どうすればそのまま相手に渡せるのでしょうか。
ミナトが画面から作り始めていたら、どうなったでしょうか。焼き上がりの通知は朝7時にも届き、売り切れは知らせず、常連さんの欲しいものとは違う仕組みができていたはずです。作り直すほど費用はかさみます。システム開発では、作り始める前に「このシステムは何をしなければならないか」を決め、関係者のあいだで合意しておきます。この、利用者の要求を集めて整理し、システムが満たすべき要件としてはっきりさせる一連の作業を要件定義プロセスと呼びます。
要件定義は、ふつう二段に分けて進めます。先に来るのは、システム全体として何を実現するかを決めるシステム要件定義です。企画の次に置かれる工程で、ここで決めた、システムが満たすべき機能・性能・制約などの要求事項をシステム要件といいます。「焼き上がりと売り切れを登録した人に知らせる」「朝7時台には送らない」は、どちらも焼き上がり通知のシステム要件です。
決めた要件は、口約束にしません。開発の対象範囲と実現する機能・性能を文書にまとめ、発注する側と開発する側が同じ文面を読んで合意します。この文書が要件定義書です。店長が「売り切れも知らせてって言ったよね」と言い、開発会社が「聞いていません」と答える。そうした食い違いを後から確かめられるのは、書いて残してあるからです。
ここから基本情報！要件を決める前の下調べ
システム要件を決める手がかりになるのが、誰がどんな目的で、どんな場所でシステムを使うのかという前提です。どのような利用者が、どのような課題（目標や作業）のために、どのような環境で使うのかを明らかにしたものを利用の状況といいます。焼き上がり通知なら、使うのは近所の常連さんで、目的は焼きたてを買いに来ること、環境は通勤前や家事の合間に見るスマートフォンです。
利用の状況が「誰が・何のために」なら、それを時間の流れに沿って書いたものが運用シナリオです。「店員が焼き上がりを登録する。登録した常連さんに通知が届く。最後の1個が売れたら、売り切れの通知が届く」のように、運用が始まった後の業務とシステム操作の手順を具体的に書きます。シナリオに沿って考えると、どこからどこまでをシステムが受け持つのかという境目が見えてきます。
基本情報の範囲ここまで
焼き上がり通知は、お客さんにとっては「焼きたてを逃さない」という価値を持つ仕組みです。提供する側が、利用者に価値をもたらすために提供する、形のない働きや成果をサービスと呼びます。パンそのものは形がありますが、通知は形がありません。システム要件を考えるときには、システムを通して利用者にどんなサービスを届けるのかを先に決めておきます。
システムの境目を決めると、外とどうつながるかも決めることになります。通知をスマートフォンへ届ける仕組みを、こむぎ堂がいちから作る必要はありません。スマートフォンのOSや通知の配信サービスは、外のプログラムから機能を呼び出せる窓口を公開しています。あるソフトウェアの機能を、ほかのソフトウェアから呼び出して使えるようにした取り決めをAPI（Application Programming Interface）といいます。焼き上がり通知のプログラムは、配信サービスのAPIに「この人にこの文を送って」と頼むだけで済みます。
ここから基本情報！APIを組み合わせる
APIは一つだけでなく、いくつも組み合わせて使えます。通知の配信サービスのAPIに地図サービスのAPIを組み合わせれば、「店まで徒歩5分の人にだけ知らせる」こともできます。複数の提供元が公開しているAPIなどを組み合わせ、新しいサービスを作り出す手法をマッシュアップと呼びます。
基本情報の範囲ここまで
人とのつながり方も決めます。常連さんがパンを選ぶ画面には、パンの写真とボタンが並び、指で触れて操作します。アイコンやボタンなどの画面部品を、マウスや指で直接操作して使う方式をGUI（Graphical User Interface）といいます。文字でコマンドを打ち込む方式と比べ、初めての人でも操作を覚えやすいのが特徴です。
ここから基本情報！ほかの仕組みとの受け渡しと機能の仕様
システムどうしがデータを受け渡すのは、APIを通してだけではありません。店長は月末に、通知の件数をレジの売上と並べて見たいと言います。そこで、通知の記録を決まった形式のCSVファイルに書き出し、表計算ソフトや会計の仕組みに読み込ませます。このように、システムと別のシステムや外部の媒体とのあいだでデータをやり取りするために、形式を決めて作るファイルをインタフェースファイルといいます。
境目と外とのつながりが決まったら、システムが実現する機能を一つずつ具体的に書き出します。「パンを登録する」「焼き上がりを登録する」「通知を送る」「売り切れを知らせる」の一つ一つについて、何を受け取り、何をして、何を返すのかを書いたものがシステム機能仕様です。あわせて、通知が何秒で届くか（レスポンスタイム）や、1分間に何件の通知を送れるか（スループット）といった性能の目標もまとめておきます。
基本情報の範囲ここまで
1-2機能要件と非機能要件
ミナトは聞き取りのメモを1枚ずつ付箋に書き写し、作業台に並べました。「焼き上がりを知らせる」「売り切れを知らせる」「朝7時台は送らない」「焼けてから1分以内に届く」。並べてみると、付箋の書き方に2種類あることに気づきます。
付箋の前半の2枚は、システムが「何をするか」を書いています。焼き上がりを知らせる、売り切れを知らせる。このように、システムが行う処理や動作そのものについての要件を機能要件といいます。業務の流れのどこをシステムに任せるのかを、利用者に見える働きとして書いたものです。
後半の2枚は様子が違います。「1分以内に届く」は、知らせるという機能がどれだけ速く動くかを決めています。機能そのものではなく、性能・信頼性・セキュリティ・使いやすさのように、機能以外の面についての要件を非機能要件といいます。速さ、止まらなさ、守りの固さ、使いやすさ、直しやすさ、といった性質がここに入ります。
では「朝7時台は送らない」は、どちらでしょうか。迷ったミナトに、相棒は「その条件を守らせる処理を、システムが行いますか」と聞き返しました。送る時刻を判断して7時台には送らないという働きは、システムがする処理なので、機能要件として書くのが自然です。一方「1分以内に届く」は、どんな処理をするかではなく、処理の速さの目標なので非機能要件です。
ここから基本情報！機能以外の要件をさらに分ける
非機能要件は、さらにいくつかに分けて書くと漏れにくくなります。まず、信頼性・性能効率性・使いやすさ・保守性・セキュリティといったソフトウェアの品質について求めることを品質要件といいます。品質の見方を何に分けるか（品質特性）は、第2章で設計とあわせて扱います。
次に、システムを動かす場所についての決まりです。「お客さんの画面はAndroidとiOSの両方で動く」「通知のサーバはクラウドの上に置く」のように、OS・ハードウェア・ネットワークなど、システムを稼働させる環境についての要件を実行環境要件といいます。
周りの機器やほかのシステムとのつなぎ方も決めておきます。オーブン横に置く焼き上がり登録のボタンをどう接続するか、レジの仕組みとどんな形式でデータを受け渡すか。周辺の機器や外部のシステムとの接続や通信の方式についての要件を周辺インタフェース要件といいます。
最後に、作り方の自由を狭める条件があります。「予約システムと同じ会員の名簿を使う」「開発会社がふだん使っている言語で作る」のように、使う言語・基盤・既存のシステムなどから決まる、設計や実装のうえで従わなければならない制約を実装制約条件といいます。こむぎ堂の場合、去年作った予約システムの会員の名簿を使い回すことが、いちばん大きな制約でした。
基本情報の範囲ここまで
1-3業務・組織・利用者の要件
機能と非機能に分けた付箋を見て、店長が言いました。「これで全部だよね」。相棒は、付箋に書かれていないことをいくつか尋ねます。お客さんの登録は何年残しますか。通知が止まったら、誰がどこに連絡しますか。店員さんはボタンの押し方をどこで覚えますか。店長は少し考えてから「それも決めなきゃいけないのか」と笑いました。
要件は、利用者がシステムに「何をしてほしいか」だけでは足りません。システムは店の業務の中で使われ、店員が操作し、止まれば誰かが直し、お金をかけて作ります。業務の手順、組織の体制、利用者が使えるようになるまでの準備といった、業務・組織・利用者からの要求も、システム開発の項目に一つずつ対応させて書いておきます。相棒の質問は、どれもこの種類の要件を聞き出そうとしていました。
ここから基本情報！データ・守り・移行・テストの要件
一つめの質問は、データについてでした。お客さんの名前、登録したパン、送った通知の記録を、どんな構造で、どれだけの量、どれだけの期間持っておくのか。システムで扱うデータの構造・容量・保存期間などについての要件をデータベース要件といいます。通知の記録を1年で消すのか、ずっと残すのかで、必要な記録の容量は大きく変わります。
登録した人の連絡先は、店の外に漏れてはいけません。誰が登録者の一覧を見られるのか、通信を暗号化するのか、ログインに何を求めるのか。情報の機密性・完全性・可用性を保つためにシステムに求める守りについての要件をセキュリティ要件といいます。
こむぎ堂には、紙の「取り置き希望ノート」に名前と好きなパンを書いてもらっていた常連さんが30人ほどいます。そのノートの中身を新しい仕組みにどう移し、いつから紙をやめるのか。今の仕組みから新しいシステムへ、データや業務をどう切り替えるかについての要件を移行要件（システム移行要件）といいます。移す方法、手順、移し終えたと判断する条件までを決めておきます。
出来上がったシステムを受け取るとき、何を確かめれば「要件どおり」と言えるのかも、先に決めておきます。「焼き上がりを登録してから1分以内に、登録者全員に届くことを確かめる」のように、テストで確認する項目や合格の基準を定めたものがテスト要件です。
基本情報の範囲ここまで
動き始めた後の店の毎日についても、要件はあります。誰が監視し、止まったらどうするのか。店員は使い方をどう覚えるのか。そして全部でいくらかかるのか。小さなパン屋でも、この三つを決めずに始めると、通知が止まった朝に誰も気づかない、ということが起きます。
ここから基本情報！運用・保守・人・お金の要件
システムを何時から何時まで動かし、誰がどうやって監視し、記録の控え（バックアップ）をいつ取るのか。日々の運用についての要件を運用要件といいます。焼き上がり通知は、店が開く前の6時から閉店の19時まで動いていれば足ります。
運用が始まった後には、不具合を直したり、新しいパンを足したりする作業が必ず出てきます。その作業のしやすさや、誰がどの範囲を直すのかについての要件が保守要件です。また、通知が届かなくなったときに、どう気づき、誰に連絡し、どの手順で元に戻すのかを定めておくのが障害対応の要件です。
システムは、使う人が使えなければ動いていないのと同じです。店員がボタンの押し方や、登録者の一覧の見方を覚えるための説明や研修を教育といいます。シラバスでは教育と並んで訓練が挙げられています。教育が知識を伝えることだとすると、訓練は実際に手を動かして操作や対応に慣れておくことを指すと考えられます。たとえば、通知が止まったという想定で、店員が連絡と再起動の手順を一度通しでやってみる、といったものです。
最後に費用の要件があります。作るのにいくらかかるかだけでなく、通知の配信サービスの月々の料金や、直してもらうときの料金まで含めて、開発・運用・保守にかかるお金の上限を決めておきます。店長にとっては、ここがいちばん気になる付箋でした。
基本情報の範囲ここまで
1-4要件の評価とレビュー
要件定義書の下書きができた金曜の夕方、開発会社の担当者がこむぎ堂に来ました。店長・ミナト・担当者の3人で、下書きを1行ずつ声に出して読みます。「売り切れの通知は、登録した人全員にですか、焼き上がり通知を受け取った人だけにですか」。担当者のその一言で、店長も答えに詰まりました。
書いた本人が何度読み返しても、書き漏らしや思い込みは見つけにくいものです。そこで、要件定義書を作ったら、システムを発注する側（取得者）と作る側（供給者）が一緒に読み、要件が正しく、漏れなく、実現できるものになっているかを確かめます。このように、作成者以外を含む複数の関係者が集まって、文書や成果物を一緒に確かめ、誤りや問題点を洗い出すことを共同レビューといいます。担当者の問いは、店長の頭の中では当たり前だったことを、文書に書かせる働きをしました。
レビューで確かめるのは、要件がこむぎ堂の望みに合っているか、互いに食い違っていないか、費用と期間の中で作れるか、テストで確かめられる書き方になっているか、といった点です。「なるべく早く届く」は、何分以内なら合格なのかが分からないので、テストで確かめられません。「1分以内に届く」と書き直します。
ここから基本情報！要件を後からたどれるようにする
「1分以内に届く」という要件は、この先、設計書のどこかで仕組みになり、プログラムのどこかで実装され、テストのどこかで確かめられます。その対応が途中で切れると、作ったのに誰も確かめていない要件や、どの要件のためにあるのか分からないプログラムが生まれます。要件から設計・実装・テストへと順にたどれるだけでなく、テストやプログラムから逆向きに元の要件へもたどれる性質を双方向の追跡可能性（双方向のトレーサビリティ）といいます。
この対応を確かめるために作るのが、要件を行に、設計書の項目・プログラム・テストケースを列に並べ、対応する所に印を付けた表です。これをトレーサビリティマトリクスと呼びます。行に印が一つも無ければ、その要件はまだどこにも実現されていません。列に印が無ければ、そのプログラムはどの要件にもつながっていません。
| 要件 | 設計：通知の送信 | 設計：送る時刻の判定 | テスト：1分以内に届く | テスト：7時台は送らない |
|---|---|---|---|---|
| 焼き上がりを1分以内に知らせる | ○ | ○ | ||
| 朝7時台は送らない | ○ | ○ | ||
| 売り切れを知らせる | ○ |
表の3行目を見ると、「売り切れを知らせる」に対応するテストがまだありません。表にしたことで、確かめる手段の抜けが一目で分かります。
レビューを開くときには、誰を呼び、どう進めるかも決めておきます。要件を読むのに必要な立場の人、たとえば店長（要件を出す人）、店員（実際に使う人）、開発会社の担当者（作る人）を選びます。こうして確認の場に出て、内容を確かめ、指摘や承認をする関係者をレビュー参加者といいます。
進め方にも種類があります。作成者が説明しながら参加者と一緒に文書をたどる形（ウォークスルー）もあれば、進行役を立て、点検の項目と手順を決めて公式に行う形（インスペクション）もあります。どの形式・手順でレビューを行うかをレビュー方式といいます。それぞれの方式の違いは、第3章で扱います。
基本情報の範囲ここまで
1-5ソフトウェア要件定義
システム要件の読み合わせが終わると、開発会社の担当者は「ここからは、ソフトウェアの部分をもう一段細かく決めます」と言いました。ボタンは機械、知らせを送るのはプログラム、ボタンを押すのは店員。担当者は、全体をこの三つに振り分けた図をすでに描いていました。プログラムが受け持つ部分だけを取り出して、もう一度要件を書き直すのだといいます。
システム全体の要件が決まると、次はシステムをハードウェア・ソフトウェア・人の作業に振り分け、全体の構成を決めます（システム方式設計。第2章で扱います）。その後に来るのが、開発するソフトウェアについて、求められる機能・性能・インタフェースなどをはっきりさせるソフトウェア要件定義です。ここで決める、ソフトウェアが満たすべき要求事項をソフトウェア要件といいます。
システム要件とソフトウェア要件の違いは、細かさと範囲にあります。システム要件の「焼き上がりを1分以内に知らせる」には、店員がボタンを押す時間も、ボタンの信号が届く時間も含まれます。ソフトウェア要件では、そのうちプログラムが受け持つ部分を取り出し、「焼き上がりの信号を受け取ってから30秒以内に、配信サービスへ送信を頼む」のように、ソフトウェアの言葉で書き直します。
ここから基本情報！ソフトウェアを単位に分ける
焼き上がり通知のソフトウェアは、お客さんのスマートフォンで動くアプリと、店の通知のサーバで動くプログラムの二つに分かれます。開発と管理のために一つのまとまりとして扱う、こうしたソフトウェアの単位をソフトウェア構成品目といいます。ソフトウェア要件は構成品目ごとに定め、版の管理（構成管理）もこの単位で行います。
基本情報の範囲ここまで
ソフトウェア要件を決めるには、店の業務がどう流れているのかを、まず見える形にします。業務の処理の手順や、その中を流れる情報の動きを図にして表したモデルを業務プロセスモデルといいます。代表的な描き方が、この章の後半で扱うDFD（データの流れを描く図）です。業務の「動き」を表す業務プロセスモデルに対して、業務で扱うデータの「形」を表すのがデータモデルで、E-R図などで描きます。
ここから基本情報！業務とデータをモデルにする
対象の業務の流れや仕組みを分析し、図などのモデルとして表す作業を業務モデリングといいます。こむぎ堂では、「焼き上がる→店員がボタンを押す→通知が届く→お客さんが来店する→売れる→残りが0個になる→売り切れが届く」という流れを図にしました。
業務で扱うデータの実体（お客さん、パン、通知）と、その属性（名前、パンの名前、送った時刻）、実体どうしの関連（お客さんがパンを登録する）を分析して表す作業がデータモデリングです。業務モデリングが業務の流れを、データモデリングがデータの構造を受け持ちます。
基本情報の範囲ここまで
業務の処理とデータは、別々に描いただけでは関係が見えません。そこで、処理を行に、データを列に並べ、それぞれの処理がそのデータを作る（Create）・読む（Read）・書き換える（Update）・消す（Delete）のどれをするのかを、頭文字で書き込んだ表を作ります。これをCRUD図といいます。
| 処理＼データ | お客さん | パン | 通知の記録 |
|---|---|---|---|
| お客さんがパンを登録する | C | R | |
| 店員が焼き上がりを登録する | U | ||
| 通知を送る | R | R | C |
| 登録をやめる | D |
表を作ってみると、「通知の記録」を消す処理が一つもないことが分かります。このままでは記録が増え続けるので、「1年たった記録を消す」処理を足すか、ずっと残すのかを決めなければなりません。CRUD図は、処理とデータの対応を確かめ、こうした抜けを見つけるために使います。
ここから基本情報！提供するサービスと守りの方式
業務とデータが見えたら、ソフトウェアが利用者に提供する機能やサービスの範囲と内容をはっきりさせます。「登録できるパンは1人5種類まで」「通知は焼き上がりと売り切れの2種類」のように、提供するものと、提供しないものの境目を決める作業をサービスの定義といいます。
システム要件で決めたセキュリティ要件は、ソフトウェア要件では、どの技術で実現するかまで落とし込みます。「登録者の一覧を見られるのは店長だけ」という要件に対して、パスワードと確認コードの2つでログインさせる、通信はすべて暗号化する、と決めるのがその例です。セキュリティ要件を満たすために、認証や暗号化などのどの仕組みを使うかを定めたものをセキュリティ実現方式といいます。
基本情報の範囲ここまで
1-6ヒアリングとプロトタイプ
最初の聞き取りでは、常連さんの話があちこちに飛び、ミナトのメモは半分しか読めませんでした。「売り切れも知りたい」と言ったのが誰だったのかも、もう分かりません。2回目の前に、相棒は「誰に、何を、どの順で聞くかを先に決めておきましょう」と言いました。
要件の多くは、利用者の頭の中にあります。それを取り出すいちばん基本の方法が、利用者に直接話を聞くヒアリングです。ただ、話を聞くだけでは、聞きたいことが聞けず、聞いたことも残りません。聞く前に準備をし、聞いた後に記録して確かめる、という手順を踏みます。
ここから基本情報！聞き取りの準備と記録
聞き取りの前に、誰に（朝に来る常連さん3人と、夕方に来る人2人）、何を（通知を受け取りたい時間帯、知りたい中身）、どうやって（店の作業台で1人15分）聞くかを決めておきます。このように、要求を聞き取る相手・項目・やり方・日程を前もって定めたものをヒアリング計画といいます。
聞き取りの場で出た発言や確かめた事柄、決まったことは、その日のうちに文書にまとめます。これがヒアリング議事録です。「売り切れも知りたい（佐藤さん。焼き上がりより大事とのこと）」のように、誰の発言かも残します。議事録は話した相手に見せ、聞き違いが無いかを確かめてもらいます。
基本情報の範囲ここまで
聞き取りには限界もあります。「どんな画面がいいですか」と聞かれても、見たことのない画面を思い描いて答えるのは難しいものです。反対に、紙に描いた画面を見せると、常連さんはすぐに「この字、小さくて読めないよ」と指さしました。形のあるものを見せると、言葉だけでは出てこなかった要求が出てきます。
ここから基本情報！試しに作って見せる
本格的に作る前に、要件や操作のしやすさを早いうちに確かめるために作る試作品をプロトタイプといいます。ミナトが作りかけていた「焼き上がりました」の画面も、本番用ではなく試作として使えば役に立ちます。ボタンを押すと画面が切り替わる程度の、実際に触って動かせるものを作り、利用者の思い違いや要件の漏れを早く見つけます。
似たものに、モックアップがあります。画面の見た目や配置を確かめるための、動かない模型です。紙に描いた画面や、画像として作った画面がこれにあたります。触って動かせるかどうかが、プロトタイプとの違いです。
作った試作品を利用者に実際に使ってもらい、要求に合っているかを確かめる作業をプロトタイプ版評価といいます。こむぎ堂では、常連さん3人にスマートフォンで試作の画面を触ってもらいました。「パンを選んだら、それで終わり？」という声が出て、登録が済んだことを知らせる表示を足すことになりました。
基本情報の範囲ここまで
1-7ユースケースとユーザーストーリー
聞き取りの議事録は、3枚にもなりました。ミナトがそれを要件定義書に写そうとすると、相棒が「議事録を発言の順に写すのではなく、使う人が何をしたいのか、1つずつの目的に分けてみましょう」と言います。常連さんがしたいのは「好きなパンを登録すること」と「焼きたてを知ること」。店員がしたいのは「焼き上がりを伝えること」でした。
システムに求めることを、使う人の目的ごとに区切って書く方法があります。利用者がシステムを使って一つの目的を果たすまでの、利用者とシステムのやり取りの流れを記述したものをユースケースといいます。「好きなパンを登録する」「焼き上がりを知らせる」が、焼き上がり通知のユースケースです。機能を開発する側の都合で並べるのではなく、使う人から見た目的で区切るところに特徴があります。
ここから基本情報！システムの外にいる登場者
ユースケースを使うのは人とは限りません。焼き上がり通知では、常連さんと店員のほかに、通知の配信サービスもシステムの外からやり取りします。システムの外にいて、システムとやり取りする人や外部のシステムをアクター（アクタ）と呼びます。アクターは個人ではなく役割を表すので、店長がボタンを押すときは、店長も「店員」というアクターとして扱います。
基本情報の範囲ここまで
ユースケースの中身は、やり取りを順に書いていきます。「好きなパンを登録する」なら、①お客さんがアプリを開く、②パンの一覧が表示される、③お客さんがメロンパンを選ぶ、④登録が済んだことが表示される、という流れです。このように、ユースケースの中で利用者とシステムがどんな手順でやり取りするかを具体的に書いたものをシナリオといいます。うまくいく流れのほかに、「すでに5種類登録している」のように、途中で別の道に分かれる流れも書いておきます。
要求の書き方には、もっと短いものもあります。「常連として、メロンパンが焼けたら知りたい。焼きたてを買いに行けるから」。このように、利用者の立場から、誰が、何を、なぜ欲しいのかを短い文で表したものをユーザーストーリーといいます。アジャイル開発で、要求の単位としてよく使われます。「なぜ」まで書くので、作る人が目的を取り違えにくくなります。
ここから基本情報！ストーリーの大きさ
「常連として、店の焼きたての情報をスマートフォンで全部受け取りたい」という要求は、1つのユーザーストーリーとしては大きすぎます。焼き上がり、売り切れ、新商品の知らせなど、いくつかのストーリーに分けて扱うことになります。このように、複数のユーザーストーリーにまとめて分けて扱う、大きな粒度の要求をエピックと呼びます。
分けたストーリーには、作るのにどれくらいかかるかの見当を付けます。時間や日数で言い当てるのは難しいので、基準にしたストーリーと比べて何倍くらいの大きさかを、数で表します。ユーザーストーリーを実装する大きさや複雑さを相対的な数で表した単位をストーリーポイントといいます。「パンを登録する」を2とすると、「売り切れを知らせる」は残りの個数を数える必要があるので5、といった付け方です。
基本情報の範囲ここまで
集めたユーザーストーリーは、優先する順に一つの列に並べます。スクラムでは、プロダクトに必要な機能や要求を、優先順位を付けて並べた一覧をプロダクトバックログといい、プロダクトオーナーが管理します。こむぎ堂の一覧では、店長の判断で「焼き上がりを知らせる」が先頭、「新商品を知らせる」は最後になりました。並べ替えは、作っている途中でも行います。
ここから基本情報！小さく作って繰り返す
一覧の上から順に、数週間ずつ区切って作っていけば、最初の区切りで「焼き上がりを知らせる」だけが動く版ができ、次の区切りで売り切れが加わります。開発する対象を分け、設計・実装・評価を含む同じ工程の一回りを何度も繰り返して、少しずつ完成に近づける開発モデルを繰返し型モデルといいます。一回りごとの結果を見て、次に作るものを決め直せます。
基本情報の範囲ここまで
1-8DFD
開発会社の担当者が、ホワイトボードに丸と矢印と二本線を描き始めました。「焼き上がり」という矢印が丸に入り、丸から「通知」という矢印が出ていきます。二本線のあいだには「登録者」と書かれていました。ミナトには、何の図なのかすぐには分かりませんでした。
担当者が描いていたのは、業務の中でデータがどこから来て、どこで処理され、どこにためられ、どこへ出ていくかを表す図です。この図をDFD（Data Flow Diagram）といいます。ソフトウェア要件定義の節で見た業務プロセスモデルを描く、代表的な方法の一つです。処理の順番や条件分岐ではなく、データの流れだけに目を向けて描くのが特徴です。
ここから基本情報！DFDの記号と描き方
DFDを使ってデータの流れを分析し、システムの機能を上から順に細かく分けていく分析の手法を構造化分析法といいます。DFDは4種類の記号で描きます。記号の形には流派があり、ここでは試験でよく見るデマルコ式（処理を丸で描く形）で説明します。
矢印は、処理やデータの置き場所のあいだをデータが移る道筋を表し、データフローと呼びます。丸は、データを受け取って加工し、別のデータとして出す処理（プロセス）です。二本線は、データをためておく場所を表すデータストアで、ファイルやデータベースにあたります。四角は、システムの外にいてデータを出したり受け取ったりする外部実体（店員やお客さん）です。
| 記号 | 名前 | 焼き上がり通知での例 |
|---|---|---|
| 矢印 | データフロー | 「焼き上がり」「通知」 |
| 丸 | プロセス（処理） | 「通知の相手を選ぶ」 |
| 二本線 | データストア | 「登録者」 |
| 四角 | 外部実体 | 「店員」「お客さん」 |
DFDは、いきなり細かく描きません。最初に、システム全体を丸1つで表し、外部実体とのあいだのデータの出入りだけを描きます。この最上位の図をコンテキストダイアグラムといいます。こむぎ堂なら、丸「焼き上がり通知システム」に店員から「焼き上がり」が入り、お客さんへ「通知」が出ていく、という図になります。そこから丸を「登録を受け付ける」「通知の相手を選ぶ」「通知を送る」に分け、さらにその中を分けていきます。
これ以上分けられない一番下の丸には、中で何をするのかを文章や表で書き添えます。「登録者のうち、そのパンを登録していて、いまが7時台でない人を選ぶ」のように、最下位のプロセスの処理の手順や条件を詳しく書いた仕様をミニスペックといいます。
基本情報の範囲ここまで
1-9UMLとその他の手法
DFDを描き終えた担当者は、次の打ち合わせで別の図を持ってきました。棒人間が2人並び、その横に楕円が3つ。棒人間の下には「お客さん」「店員」と書いてあります。「こっちの図は、うちの会社だけでなく、どこの開発会社でも同じ描き方で通じるんですよ」
図の描き方が会社ごとに違えば、ほかの人が描いた設計図は読めません。そこで、ソフトウェアの構造や振る舞いを図で表すための記法を、一つの標準にまとめたものがあります。それがUML（Unified Modeling Language）です。オブジェクト指向の設計で使われることが多く、目的に応じた十数種類の図が決められています。業界団体のOMG（Object Management Group）が仕様を定めています。
UMLの図は、大きく二つに分かれます。システムを形づくる要素と、そのつながりを表す図（構造図）と、システムの動きを表す図です。データのまとまり（クラス）の名前・属性・操作と、クラスどうしの関係を描くクラス図や、関係するクラスを入れ物（パッケージ）ごとにまとめて表すパッケージ図は、前の種類に入ります。クラスどうしの関係の線の端に、相手から見たそのクラスの役割（ロール名）を書き添えることもあります。
ここから基本情報！UMLの図の種類
担当者が持ってきた図は、アクターと、システムが提供する機能（ユースケース）との関係を、棒人間と楕円と線で表したもので、ユースケース図と呼びます。システムの範囲を四角の枠で囲み、その中に楕円を、外にアクターを置きます。どのアクターがどの機能を使うのかが、一枚で見渡せます。
ユースケース図は、UMLの中で、処理の流れや状態の変わり方など、システムの動きを表す図の仲間に入ります。この仲間をまとめて振る舞い図といいます。クラス図などの構造図と対になる分け方です。
振る舞い図の一つに、作業の流れを順序と分かれ道で表すアクティビティ図があります。この図で、一つ一つの作業のまとまりを表す要素をアクティビティといいます。「焼き上がりを受け取る」→「7時台か？」→「7時台でなければ通知を送る」のように、角の丸い四角で表した作業を矢印でつなぎ、ひし形で道を分けます。なお、UML 2 では、それ以上分けない一つ一つの作業をアクション、それらをつないだ流れ全体をアクティビティと呼び分けます。DFDでは描けなかった条件の分かれ道を、こちらでは描けます。
ものの状態の移り変わりを描く図もあります。メロンパンは「焼成中」→「販売中」→「売り切れ」と状態を変え、「焼き上がり」「最後の1個が売れた」という出来事で次の状態へ移ります。オブジェクトが取りうる状態と、どんな出来事や条件で状態が移るかを表す図をステートチャート図といいます。いまのUML（UML 2）では、ステートマシン図（状態機械図）と呼ばれています。
オブジェクトどうしのメッセージのやり取りを表す図は、二つあります。時間の流れを縦軸に取って、やり取りの順番を表すのがシーケンス図です。これに対して、オブジェクトの配置とつながりを描き、その上にメッセージを番号付きで書き込むのがコラボレーション図です。コラボレーション図はUML 1の名前で、UML 2ではコミュニケーション図に名前が変わりました。
UMLはソフトウェアのための記法ですが、焼き上がり通知には、ボタンという機械も含まれます。UMLを拡張して、ハードウェアを含むシステム全体の要求・構造・振る舞いを表せるようにしたモデリング言語がSysML（Systems Modeling Language）です。要求そのものを図に描く要求図など、UMLには無い図も持っています。仕様はUMLと同じOMGが定めていて、2025年に正式に採択されたSysML v2では、UMLから切り離した独自の言語として作り直されました。
図や日本語の文章では、どうしても読み方に幅が出ます。「焼けたらすぐ知らせる」の「すぐ」は、人によって違います。そこで、仕様を数学の記法で厳密に書き、あいまいさを無くして、矛盾が無いかを機械的に確かめられるようにする手法があります。これを形式手法といいます。手間がかかるので、鉄道や航空のように、誤りが許されない仕組みで使われることが多い手法です。
基本情報の範囲ここまで
1-10開発規模の見積り
要件定義書がほぼ出来上がったころ、店長が開発会社の担当者に聞きました。「それで、結局いくらかかるの？いつ出来るの？」。担当者は「何を作るかが決まったので、ようやく大きさが測れます」と答え、要件定義書の機能の一覧を指で数え始めました。
開発にかかる費用と期間は、作るソフトウェアの大きさ（開発規模）から見積もります。規模が分かれば、それを作るのに必要な作業の量（工数。何人で何日、という量）が分かり、工数から費用と期間が決まります。要件定義が終わるまで正確な見積りができないのは、何を作るかが決まらないと、規模が測れないからです。見積りの方法はいくつかあり、手がかりにするものが違います。
一つめは、ソフトウェアの機能の数と複雑さから規模を測る方法です。画面からの入力、通知や帳票などの出力、照会、内部で持つデータのまとまり、外のシステムから参照するデータの5種類について数を数え、それぞれ複雑さに応じた重みを掛けて点数（ファンクションポイント）を合計します。この方法をファンクションポイント法（FP法）といいます。プログラムの行数ではなく、利用者から見える機能で測るので、作る言語が決まっていない段階でも使えます。
焼き上がり通知で数えてみます。重みは、どれも複雑さが「ふつう」として、よく使われる値（入力4、出力5、照会4、内部のデータ10、外部のデータ7）を使います。
| 種類 | 焼き上がり通知の中身 | 数 | 重み | 点数 |
|---|---|---|---|---|
| 外部入力 | パンの登録、焼き上がりの登録、売り切れの登録 | 3 | 4 | 12 |
| 外部出力 | 焼き上がりの通知、売り切れの通知 | 2 | 5 | 10 |
| 外部照会 | 登録したパンの確認 | 1 | 4 | 4 |
| 内部論理ファイル | お客さん、パン | 2 | 10 | 20 |
| 外部インタフェースファイル | 予約システムの会員の名簿 | 1 | 7 | 7 |
| 合計 | 53 | |||
合計は53ファンクションポイントです（実際には、この後に処理の難しさなどで点数を補正します）。開発会社の過去の実績が「1ファンクションポイントあたり0.5人日」だとすれば、工数は53×0.5でおよそ27人日、という見当が付きます。
二つめは、過去の似た開発と比べる方法です。担当者は「去年こむぎ堂さんの予約システムを作ったとき、30人日かかりました。今回は画面が少ないので、それより少し小さいくらいでしょう」と言いました。このように、過去に行った似たシステムの開発の実績をもとに、新しい開発の規模や工数を見積もる方法を類推見積法（類推法）といいます。早い段階で手早く見積もれる反面、比べる開発が本当に似ているかどうかで、当たり外れが大きくなります。
三つめは、基準を一つ決め、それと比べて大きさを付ける見方です。「パンを登録する」機能の大きさを1としたとき、「売り切れを知らせる」はその2倍くらい、と比べて見積もります。ITパスポートのシラバスでは、こうした見積りを相対見積という語で挙げています。人は、ものの大きさを数で言い当てるより、二つを比べるほうが得意だという考え方に立つ方法で、アジャイル開発で使うストーリーポイントは、この見積りの代表です。
四つめは、作業を細かく分け、それぞれにかかる工数を見積もって足し上げる方法で、積算法といいます。作業を分けた一覧（WBS）があれば使えます。
| 作業 | 工数 |
|---|---|
| お客さんのアプリの画面を作る | 8人日 |
| 通知のサーバのプログラムを作る | 10人日 |
| 焼き上がりのボタンをつなぐ | 3人日 |
| 全体のテスト | 5人日 |
| 合計 | 26人日 |
一つ一つの作業は見積もりやすいので、細かく分けるほど根拠ははっきりします。そのかわり、一覧から漏れた作業は、合計にも入りません。
翌週の月曜、作業台に要件定義書が2部並びました。FP法でおよそ27人日、積算法で26人日。二つの見積りがほぼそろったのを見て、店長は費用の欄に納得したようにうなずきます。最後に、開発会社の担当者がいちばん上の1行を読み上げました。「焼き上がりと売り切れを、登録した人に知らせる。朝7時台は送らない」。店長とミナトと担当者は、それぞれの名前を書き入れました。
常連さんの「売り切れも知りたい」は、こうして要件定義書の1行になりました。店長の「焼きたてを知らせたい」という一言が、誰に、いつ、何を知らせるのかまで決まった文章に変わり、開発会社と同じ紙の上で確かめられるようになっています。最初の日にミナトが作りかけた画面は、試作として常連さんの指摘を集め、役目を終えました。
ただ、要件定義書には「何をするか」は書いてあっても、「どうやって」は書いてありません。店員は焼き上がりを、どうやってシステムに伝えるのか。オーブンに機械を付けるのか、ボタンを押すのか、表に手で打ち込むのか。担当者は帰り際に「次は、それを決めましょう」と言いました。