機能要件は3階層で整理：ITpro（情報元のブックマーク数）
機能要件はわかりやすく、そして、ポリシーをもってか。。。。難しいな。
全体業務フロー図の狙いは、1枚の資料でシステム全体を俯瞰できるようにすることだ。「注文処理」や「情報配信」「取引規制」などの機能群を、どの粒度でどのように分類するのが最善かを検討しやすくなると期待した。
機能要件は3階層で整理 | 日経 xTECH（クロステック）
2階層目の「業務フロー図」には、「注文処理」「情報配信」などの具体的な業務処理を進めるとき、機能群がどのようにメッセージをやり取りするかを記述した。さらに「注文処理」といった機能群を細分化した業務要件を3階層目の「要件定義書」に記載した。
機能要件は3階層で整理 | 日経 xTECH（クロステック）
軽く死ねる。。。。要求定義、チェックリスト・・・・膨大な量・・・
Wモデルによって要件定義書の品質向上が期待できる。だが一方で、要件定義工程の作業は大幅に増える。1500ページに及んだ要件定義書を作るだけでも挑戦的な取り組みなのに、さらに5000パターンを超えるチェックリストを作るとなればなおさらだ。
機能要件は3階層で整理（2ページ目） | 日経 xTECH（クロステック）
実際、当初は負荷がかかりすぎた影響で開発チームによる記述のルールや粒度にバラつきが生じた。チェックリストは要件定義フェーズの成果物ではないため、要件定義書に比べて管理が行き届かなかった。
各チームで記述をそろえないとチェックリストとしての体をなさない。そこでチェックリストの記述ルールも厳密に決めた。合計5000以上のパターンを「中項目」「小項目」の2階層で整理し、それぞれについて「板（各銘柄の注文を売り/買いの値段ごとに区分けしたテーブル）」の状態を記すルールを設けた（図4）。現行システムとの違いの明記も義務付けた。膨大な作業に追われる日々が続いたが、検収テストでの不具合と手戻りを大幅に減らせるとの信念でやり遂げた。
動いて当たり前じゃなく、数ミリ秒を争うシステムの要件は大変だ・・・だいたい、行き当たりばったりシステムは後からチューニングだしねぇー
だがarrowheadはそれでは困る。100分の1秒を競うシステムは、テスト段階のチューニングで実現できるレベルではないからだ。稼働を数カ月後に控えて「10ミリ秒を切れない」という事態は許されない。
機能要件は3階層で整理（3ページ目） | 日経 xTECH（クロステック）
そこで要件定義段階から非機能要件をきちんと決めた。性能要件なら、注文データの受付処理にかかる時間は「ザラバ（通常の取引時）」や「寄付（取引開始時）」、平常時、ピーク時などの条件も具体的かつ詳細に規定していった
うひーーー！机上で時間測定・・・机上での仮想的なシステム環境・・・すげぇ。さすが金があるだけあるわ。
実現可能性という意味では、特に性能要件がシビアだった。例えば注文受付にかかる処理時間を10ミリ秒以下と定義したわけだが、実際の処理時間は複数のプログラムによる実行時間の積み上げで決まる。
機能要件は3階層で整理（3ページ目） | 日経 xTECH（クロステック）
そこでプログラム単位で実行時間を見積もり机上検証を重ねた。C言語で記述したソースコードを想定して「この演算処理にxマイクロ秒」「このデータベースの参照にはyマイクロ秒」と試算していった。
ハードウエアに搭載するCPUやメモリー、OSやミドルウエアの処理性能を参考に机上で仮想的なシステム環境を構築し、各処理にかかる時間をできるだけ正確に見積もった。期待する性能が出ないときは、データの入出力回数を減らすなど机上でマイクロ秒単位のチューニングを重ねた。
