TSPi によるソフトウェア開発プロセス

TSPiによるソフトウェア開発プロセス 2009/03/21 Takashi Tomiyama http://mobile-robots.way-nifty.com/daily_report/

目次 • はじめに • TSPiとは • TSPiのプロセス概要 • 立ち上げプロセス • 開発戦略立案 • 開発計画立案 • 要件定義プロセス • 設計プロセス • 実装プロセス • 統合とシステムテスト • 事後分析 • 自己管理 • チームワーク • 関連情報 • 参考資料

はじめに • この資料の目的 • TSPiを勉強して理解したことを資料としてアウトプットすることで、理解した内容の定着を図る。 • 今後TSPiのプロセスに従って開発を行うときに、プロセスの概要を思い出すのに使用する。 • 動機 • 「反省の仕方」について、TSPで事後分析（ポストモーテム）というプロセスがあると聞いて、TSPを勉強してみたくなった。 • PSPに関してはいろいろなところで取り上げられているが、TSPに関してはインターネット上で（少なくとも日本語のサイトでは）情報が少ないと思ったので、資料をUploadしたら面白いかなと思った。 • 参考文献 • [1] ワッツ・S・ハンフリー著、JASPIC TSP研究会訳；TSPiガイドブック、翔泳社、2008.

TSPiとは • Introduction to the Team Software Process • チームでソフトウェを開発するためのソフトウェア開発プロセスと、そのトレーニングコース。 • 大規模開発（20人～）向けのTSP (Team Software Process)を４～５人で取り組めるように定義しなおした縮小版。 • PSP（Personal Software Process）のトレーニングを受けていることを前提とする。 • CMM, TSP, PSP • CMM 組織に対する開発プロセス改善ガイドライン • TSP チームのための開発プロセスとトレーニングコース • PSP 個人のための開発プロセスとトレーニングコース

TSPiのプロセス概要 立ち上げ開発の目的とゴールを定義し、チームを編成する。システムの構築方法と代替案を提案し、選定する。概念設計を行い、規模と時間の初期見積もりを得る。開発戦略立案開発計画立案タスク、スケジュール、品質の計画を立てる。要件定義ソフトウェア要求仕様書を作成する。製品全体を主要なコンポーネントに分割する。各コンポーネントの外部仕様を作成する。各コンポーネントの最上位ロジックを設計する。設計各コンポーネントの詳細設計と実装を行う。各コンポーネントの単体テストを行う。実装統合とシステムテスト各コンポーネントを統合して、システムテストを行う。事後分析計画と実績を比較して、プロセス改善提案を行う。

立ち上げ 開発の目的とゴールを定義し、チームを編成する。１．ゴールを設定する • 　開発対象製品の目的を定義する。 • 　製品が達成すべき不可欠な目標を定義する。 • 　完成した製品の評価基準を示す。２．チームを編成する • 　チームメンバを集める。 • 　メンバに役割を割り当てる。 • チームのゴールを定義する。 • 　メンバーの役割について話し合う。 • 　初回の開発サイクルのゴールについて話し合い、合意する。 • 　週次ミーティングを行う標準日時を設定する。３．初回ミーティングを行う

週次ミーティング • 週次ミーティングの目的 • チーム内のコミュニケーションを図り、課題を共有し、意思決定する。 • 進捗データを収集、分析、レビューして必要ならばバランスをとる。 • 報告内容 • 自分が割り当てられたタスクの活動状況 • 追跡中の課題とリスクの状況 • 計画に対してチーム全体で費やした時間とEV（獲得価値） • その週に提出された品目、変更内容、残っているタスク • 新たに発生した問題や懸念事項 • 来週の作業予定

開発戦略立案（１） システムの構築方法と代替案を提案し、選定する。概念設計を行い、規模と時間の初期見積もりを得る。１．戦略基準を確立する利用可能な開発期間を超えるリスクを最小化するような開発戦略の選定基準を定義する。製品を構成する主要なコンポーネント、各コンポーネントの主な機能、各コンポーネントの規模を洗い出す。２．概念設計を作成する • 　開発戦略の代替案を提案し、評価する。 • 　製品の機能を各開発サイクルに割り当てる。 • 　機能の分割方法と統合方法を定義する。３．開発戦略を選択する • 　概念設計を元に、現在のサイクルの成果物について規模と時間を見積もる。 • 　次回以降のサイクルの成果物について大まかな規模と時間を見積もる。４．初期見積もりを行う

開発戦略立案（２） システムの構築方法と代替案を提案し、選定する。概念設計を行い、規模と時間の初期見積もりを得る。５．リスクを評価するプロジェクトのリスクを特定、評価し、ITL（※）に記入する。 • 　戦略記述フォームに開発する機能をリストアップする。 • 　機能を組み込む予定の開発サイクルを記入する。６．戦略を文書化する７．構成管理計画を作成する • 　構成管理の手順を定義する。 • 　サポートツールを準備する。 ※ILT： Issue Tracking Log（課題追跡ログ）。

TSPiにおける開発戦略とは • 以下のセットを開発戦略という。 • 製品機能を定義、設計、実装、テストする順序 • 将来の開発サイクルで製品を拡張する方法 • 開発作業をチームメンバ間で分担する方法 • 開発戦略は、規模見積もりとリソース計画を行うために、TSPiプロセスの最初に作成する。

概念設計 • プロジェクト計画を策定するために概念設計を行う。 • ユーザの要求をまとめた文書は自分が提供するものを記述したものではないので、計画には使えない。 • 概念設計はあくまで計画立案のツールなので、ここで多大な時間を使ってはいけない。 • 実際の設計は要求を分析し、インスペクションが完了した後。 • 概念設計を元に、仮定した製品の規模と開発に必要な時間を見積もる。 • Key Questions • 現在自分が知っている事柄に基づいて、この製品をどのように開発するのか？ • この製品を作るために必要な主要コンポーネントは何か？ • これらのコンポーネントが提供しなければならない機能は何か？ • これらのコンポーネントはどれくらいの大きさになると思うか？

開発計画立案（１） タスク、スケジュール、品質の計画を立てる。１．この開発サイクルで作成する成果物をリストアップする • 　概念設計を元に、各コンポーネントの規模を見積もる。 • 　ソースコード以外の成果物についても特定し、規模を見積もる。２．タスク計画を作成するチームとエンジニアの時間見積もりを含むタスクリストを作成する。３. スケジュール計画を作成する • 　スケジュールフォームに週次時間を記入する。 • 　チーム全体のタスクフォームを作成する。

開発計画立案（２） タスク、スケジュール、品質の計画を立てる。４．品質計画を作成する • 　各フェーズで作り込む欠陥数を見積もる。 • 　欠陥除去フェーズで達成する欠陥除去率を見積もる。５．チームメンバ個々の計画を作成する • 　各フェーズで作り込む欠陥数を見積もる。 • 　欠陥除去フェーズで達成する欠陥除去率を見積もる。 • 　チームと個々人の計画をレビューする。 • 　作業負荷のバランスがとれていない部分を特定する。 • 　タスクを割り当て直してバランスのとれた計画を作成する。６．チームの作業負荷のバランスを調整する

品質計画 • 今回の開発サイクルで作成する製品全体について、フェーズ毎の欠陥作り込み数を見積もる。 • チームが各欠陥除去フェーズで達成する欠陥除去率を見積もる。 • テストフェーズの欠陥除去率を見積もる。 • 欠陥除去率、レビューレート、インスペクションレートが基準値に近付くよう、欠陥除去フェーズの時間を増減する。（TSPiにおける用語定義）レビュー自分で作成した成果物の欠陥を探し出す作業インスペクションあるメンバが作成した成果物を複数人でレビューして欠陥を探し出す作業

計画に対して実績を追跡する • TSPiでは、プロジェクト追跡の主なメトリクスとしてPV（計画価値）とEV（獲得価値）を使用する。 • PV：Planned Value • 計画された各タスクがその仕事全体に対する割合。 • そのタスクが完了したときに初めてPVを与える。 • EV：Earned Value • その時点で完了している各タスクのPVの合計。

要件定義（１） ソフトウェア要求仕様書を作成する。１．要求記述書をレビューする • 　製品に対する要求記述書をレビューする。 • 　製品が実行すべき機能やその使われ方を明確化する。 • 　簡潔で具体的なユースケースを定義する。 • 　製品の機能と外部インタフェースについてチームで合意した内容を文書化する。２．要求仕様書（SRS）案を作成する３．システムテスト計画を作成する • 　システムがなすべきことについて合意した内容を検証するためのテスト方法を計画する。 • SRS案とテスト計画をチーム全体でインスペクションし、不整合や欠陥を見つけ出す。 • 　見つかった不整合や欠陥の修正担当者と修正期限を決める。４．SRS案とシステムテスト計画のインスペクションを行う SRS=Software Requirement Specification（ソフトウェア要求仕様書）

要件定義（２） ソフトウェア要求仕様書を作成する。５．SRS案とシステムテスト計画を更新する • 　先のインスペクションから修正／訂正された内容をSRS案とシステムテスト計画に反映させる。６．ユーザによるSRSレビューを行う • 　エンドユーザにSRS案をレビューしてもらい、望むものが記述されていることに合意を得る。７．SRSをベースライン化する • 　レビューを終えたSRSを公式にベースライン化し、以後は「変更要求手続き」でしか変更しないようにする。

SRSの目次のサンプル（TSPi版） • 目次 • はじめに • SRSの目的 • 問題の記述 • チームプロジェクト情報 • 機能要求 • システムへの機能要求 • サイクル１での要求 • サイクル２での要求 • トップダウン構造 • 要求で使われる規則の定義 • 外部インタフェース要求 • ユーザインタフェース • 画面レイアウト • 設計／実装上の制約 • 標準の順守 • 開発上の制約 • 特別なシステム要求 • 文書化 • 互換性 • 参照と情報源

テスト計画に含まれる内容 • 実行すべきテスト項目のリスト • 各テストの目標 • 各テストに必要な支援資材 • これら支援資材の予想規模 • その資材の開発にかかる時間の見積もり • その資材の開発作業の完了時期 • 欠陥がない場合の実行時間、発見される欠陥数および各テスト時間の合計の見積もり • テスト計画にある各品目を開発するために必要な作業の見積もり Support Material を直訳したものと予想。内容としてはテストに使用するテストツール、テスト用サンプルデータなど。

設計（１） 製品全体を主要なコンポーネントに分割する。各コンポーネントの外部仕様を作成する。各コンポーネントの最上位ロジックを設計する。１．上位レベルの設計を行う • 　今回のサイクルの製品構造を定義する。 • 　コンポーネントに名前を付ける。 • 　ユースケースをこれらのコンポーネントに割り当てる。２．設計標準を作成する　命名規則やインタフェース標準などの設計標準を作成する。３．設計仕様書（SDS）を作成する • 　チームメンバに設計作業を割り当てる。 • 　チームメンバはSDSのうち自分の担当分を作成する。

設計（２） 製品全体を主要なコンポーネントに分割する。各コンポーネントの外部仕様を作成する。各コンポーネントの最上位ロジックを設計する。４．統合テストの計画を作成する • 　各コンポーネントのインタフェースをレビューし、それらをテストする方法を定義する。 • 　すべてのユースケースが設計に盛り込まれているか、正しく設計されているか、統合テスト計画が適切であるかインスペクションする。 • 　見つかった不整合や欠陥の修正担当者と修正期限を決める。５．設計と統合テストの計画をインスペクションする６．SDSをベースライン化する • 　インスペクション後の更新部分をSDSに反映させ、SDSをベースライン化する。

上位レベル設計 • 製品全体の設計コンセプトを作成する。 • 最初の開発サイクルの設計フェーズで行う。 • ２回目以降のサイクルでは必要があれば変更、洗練する。 • 上位レベル設計に含まれる内容 • 製品の全体構造定義 • 製品を構成するコンポーネントの名前付け • コンポーネントに対する機能の割り付け • コンポーネントの外部インタフェース仕様 • コンポーネントに対するユースケースの割り付け

設計標準 • 命名規則 • プログラムの階層名、ファイル名、変数名など • 必要なら用語集を作る。 • コンポーネント間のインタフェース書式 • 変数、エラーコード、その他の条件 • エラーメッセージ • 一貫した、再利用可能なメッセージとメッセージ処理方法 • 欠陥標準 • 欠陥情報を収集、分析するために使用する。 • TSPiではPSP欠陥型標準を使用することを推奨 • LOCカウント標準 • LOC：Line Of Code　・・・　（ソースコードの）論理コード行数 • プログラムの規模を計測するために使用する。 • 設計表現の標準 • 設計の完全性、正確性向上に役立つ。 • レビューやインスペクション時に見落としを防ぐ。 • PSPの設計テンプレートを使ってもよい。

（参考）PSPの設計テンプレート 内部外部論理仕様テンプレート機能仕様テンプレート静的状態仕様テンプレート操作シナリオテンプレート動的詳しくは、PSPネットワークによるパーソナルソフトウェアプロセス技法の補助教材 http://www.kyoritsu-pub.co.jp/service/psp/dse_index.html の講義スライドの jlect10-1.ppt (443KB)を参照

実装（１） 各コンポーネントの詳細設計と実装を行う。各コンポーネントの単体テストを行う。 • 実装タスクを定義し、メンバーに割り当てる。 • メンバーは割り当てられたタスクの時間見積もりと作業計画を作成する。１．実装の計画を立てる • メンバーは担当分の詳細設計を行い、詳細設計書にまとめる。２．詳細設計を行う • 単体テスト計画書を作成する。 • 単体テストのテストケース、テスト手順とテストデータを作成する。３．単体テスト計画を立てる • インスペクション対象のすべてのループ、ステートマシン、実行テーブル等について適切に設計されているかインスペクションする。 • 矛盾や欠陥があれば、欠陥記録ログに記入する。４．詳細設計のインスペクションを行う

実装（２） 各コンポーネントの詳細設計と実装を行う。各コンポーネントの単体テストを行う。 • コーディングで作り込む欠陥数を見積もる。 • 各コンポーネントのソースコードを作成する。 • コンパイルエラーが除去されたソースコードについて、自己レビューを行う。 • チームメンバに参加してもらい、コードインスペクションを行う。５．コーディングとコードインスペクション６．単体テストを行う単体テスト計画書に従い、テストを実施する。コードインスペクションと単体テストが済んだコンポーネントについて、品質データをレビューし、ベースラインに入れるか修正するかを判断する。７．コンポーネントの品質をレビューする８．コンポーネントをリリースするインスペクションで問題無ければ、そのコンポーネントをリリースし、以降は構成管理の対象とする。

実装戦略 • 設計は全体像から始めて、詳細に落としていく。しかし、レビューは詳細から始めて全体像に上がっていく方が効率が良い。すなわち、レビューはボトムアップ戦略をとる方が良い。 • このボトムアップ戦略に従うために、実装も最下位レベルのオブジェクトから始めて、それからより高いレベルに移るのが良い。 • このアプローチにより、最下位レベルのオブジェクト仕様に関する問題を早期に見つけ出し、それらが広く実装される前に修正を行うことができる。 • また、最下位レベルのオブジェクトは再利用が最も簡単なので、ボトムアップ実装戦略が再利用性も促進する。

コードインスペクション • 設計にかける時間は、コーディング時間以上とすべきである。 • 設計レビューにかける時間は、設計時間の５０％以上とすべきである。 • コードレビューにかける時間は、コーディング時間の５０％以上、望ましくは７０％以上とすべきである。 • コンパ売りで見つける少なくとも倍の欠陥をコードレビューで見つける。 • レビューレートが時間当たり２００LOCを下回ることが望ましい。

統合とシステムテスト 各コンポーネントを統合して、システムテストを行う。 • 必要なビルド手順を定義する。 • 統合テスト手順とそれに必要な資材（※）を作成する。 • システムテスト手順とそれに必要な資材を作成する。 • 　各テストの規模と実行に必要な時間を見積もる。１．テストの準備を行う • 必要なすべてのコンポーネントがそろっていることを確認して、製品をビルドする。２．ビルドする３．統合テストを行う • 統合テスト計画に従い、テストを行う。 • テストデータや欠陥を記録する。４．システムテストを行う • 　システムテスト計画に従い、テストを行う。 • テストデータや欠陥を記録する。 • 　ユーザに読んでもらう文書を作成する。 • 作成したユーザ文書をレビュー、訂正して完成させる。５．文書化する ※　テストケース、テスト用サンプルデータ、評価ツールなど

統合戦略 • ビッグバン戦略 • 全てのコンポーネントを一度にまとめて統合する。 • メリット：　シンプルなシステムではテスト開発の時間が最小になる。 • デメリット：　システムが大きく複雑になるほど統合テストで見つかる欠陥が増え、原因調査と修正に時間がかかるようになる。 • 一度に一つ戦略 • 使用可能なコンポーネントを一度に一つづつ追加する。 • メリット：　問題が発生したコンポーネントを特定しやすい。 • デメリット：　テスト開発作業が多くなるかもしれない。 • 機能群戦略 • 機能ごとに関連するコンポーネントを集めて統合する。 • メリット：　テストドライバなどを開発する必要がない。 • フラットシステム戦略 • 最上位レベルのコンポーネント統合から始めて、順次下位レベルのコンポーネントに掘り下げていく。 • メリット：　システム全体に及ぶ課題を早期に検出できる。また、システム全体の骨格を早く組み上げられる。 • デメリット：　まだ使用できないコンポーネントの代わりに、数多くのスタブを用意する必要がある。

システムテストのキークエスチョン • システムは、実行することになっている機能を正しく実行するか？ • システムは、その品質ゴールを満たしているか？ • システムは、通常の条件下で正しく動作するか？ • システムは、通常でない条件下で正しく動作するか？

システムテスト戦略 • 第１案（最も一般的な方法） • 各機能のテスト • 負荷をかけた状態でのテスト • 使いやすさのテスト • パフォーマンス計測 • 第２案　（機能単位） • 選択した機能領域に焦点を合わせて網羅的にテストを行い、次第に他の機能領域に移る。 • ただし、システム全体のパフォーマンスなどを十分にチェックできないおそれがある。 • 第３案　（第１案と第２案の組み合わせ） • より下位レベルの機能を、正常、異常、および負荷のかかった状態でテストすることから始め、次第に上位レベルに移り、最後に最上位の機能をテストする。 • ただし、この方法は重要な機能の組み合わせをテストするのに時間がかかる。 • 第４案　（第３案の逆） • 最上位の機能を、正常、異常、および負荷のかかった状態でテストすることから始め、次第に下位レベルに移る。 • ただし、この方法は製品が十分高品質でないと通用しない。

文書化（Documentation） • ドキュメントがそろっていないプログラムは役に立たない。 • ユーザマニュアルの構成は製品設計の構成と大きく異なる。 • 製品の構造ではなく、読者のニーズに合わせること。 • まずは始め方を扱うべき。 • 次に、ユーザがその製品で何ができるかを説明する。 • エラーメッセージ、故障原因追究手続き、リカバリ手順に関する節を含める。 • よりユーザにとって読みやすくなるように・・・ • 用語集を使って、普通の辞書には無い用語を定義する。 • 重要なトピックには索引を付ける。 • 詳細な目次を付ける。 • 文を短く書き、シンプルな単語と言い回しを使う。 • リストや箇条書きを多用する。 • 大きな声で読み上げて、読み上げやすくなるように書きなおす。

事後分析（The Post Mortem） 計画と実績を比較して、プロセス改善提案を行う。 • チームが行ったことに関するデータを調べる。 • うまくいったところ、うまくいかなかったところを特定する。 • 問題のあるところにプロセス改善提案を出す。１．プロセスデータをレビューする • 各メンバの役割について、うまくいったところと問題があったところを特定する。 • 次回の開発サイクルに向けた改善提案を出す。２．役割のパフォーマンスを評価する３．報告書を作成する • 今回の開発サイクルにおける報告書を作成、レビュー、校正する。４．役割評価を行う • チームの実績および各役割の実施状況について自分の見解を述べる。 • 各役割の難しさと貢献度を評価する。

プロセスデータをレビューする • チームとチームメンバが行ったことに関するデータを調べる。 • そのプロセスがうまく行ったところ、うまく行かなかった所を特定する。 • チームの実績を、チームのゴールおよび計画と比較する。 • 問題のあるところと改善のニーズを特定する。 • プロセス改善を考え出して、PIP（プロセス改善提案書）にまとめる。

品質レビュー • プロセスデータのレビューの一環として、品質についてもレビューし、改善するために何が必要か見極める。 • Key Questions • 実績は計画と比べてどうだったか？ • どんな教訓をこの経験から学んだか？ • 今後、別の個人あるいはチームの基準を使うべきか？ • どこに改善の機会があると判ったか、その理由は？ • 次回訂正しなければならない問題があったか？

開発サイクルの報告書の構成 • 目次 • サマリー • 役割報告 • リーダーシップ • 開発 • 計画立案 • プロセス • 品質 • サポート • エンジニア報告 • 　自分がどのように役割を果たしたか。 • その役割の観点についてチームがどのように実施した（と自分が考える）か。チームメンバ各自の実績報告と改善提案。結論を裏付ける具体的なデータを報告に盛り込むこと。

役割評価 • チームの各メンバがチーム全体の実績に対してどの程度貢献したか評価する。 • 「役割の困難さ」と「貢献度」の視点で評価する。 • 改善の機会に焦点を合わせる。 • 素直に、正直に、客観的に、建設的に。 • 批判をするときは、次回もっとうまくその状況を処理する方法の提案を添える。

（参考）ポストモーテムの精神 • Post Mortem = 検死解剖（司法解剖） • 多くのプロジェクトは満足いく結果で終わっていない。 • （日本では）プロジェクト終了時に「反省会」が行われるが、失敗に至った経緯について弁明し、「反省の深さ」ばかり強調されて対応策の具体性が乏しい。 • 表層的な症状を裏返したものは原因に届いておらず、改善策になりえない。 • 成功も失敗も、因果関係で考える。 • 「成功のパターン」を繰り返そう！ • なぜうまくいったのか、何が効果を発揮したのか、文字にして確認しよう。 • うまくいった仕組みを見つけ出し、その「成功のパターン」を焼きつけよう。 • ポストモーテムでは、失敗だけでなく成功についても分析する。 • 計画と実績を比較し、どうだったか？ • うまく行ったところ、うまくいかなかった所はどこか？ • どこに改善の余地があると判ったか？　その理由は？ • この経験からどのような教訓を学んだか？参考　システムクリエイツ　清水氏；　ソフトウェアエンジニアのためのホームページ http://homepage3.nifty.com/koha_hp/process/Proc.Square/Proc.Square.PO.htm

自己管理 • 責任を持つ • その問題に対処することを決心する。 • 状況に左右されるのではなく、困難な状況を制御するために何ができるかを前向きに考える。 • 自分の権限や能力で対処できないことは、その権限や能力を持つ人に協力を仰ぐ。 • 現実を直視する。事実を述べる。 • 定義されたゴールに向かって努力する • 明確なゴールを定義し、焦点と優先順位を確立する。 • ゴールが不明確だと思ったら、自分の意見をまとめて、作業を開始する前にそれらについて確認、合意する。 • 堅実な原理に従って生活する • 現在の仕事に最善を尽くす。 • メンバーを理解し、相互に援助しようと努力する。 • 卓越（エクセレンス）を目指して絶え間なく努力する。 • 規律を維持するために、習慣の力を利用する。 • 習慣を自然なものとするために、願望を動機付け、知識を獲得し、技術を磨く。

チームワーク • 効果的なチームワークの８つの条件 • チームの合意されたゴール • 確立されたチームメンバーの役割 • そこで作業が行われる協力的な環境 • チームワークの共通プロセス • その作業のための計画 • チームゴール、役割と計画に対する相互のコミットメント • チームメンバー全員の間での自由でオープンなコミュニケーション • チームメンバー全員が相互に尊敬しあって支援すること

関連情報 • TSPiのフォームやスクリプト類は、Software Engineering Instituteのウェブサイトから入手可能。 • http://www.sei.cmu.edu/tsp/tools/tspi-form.html • パーソナルソフトウェアプロセス技法の補助教材 • http://www.kyoritsu-pub.co.jp/service/psp/dse_index.html • CMMIモデル　公式日本語翻訳版 • http://www.sei.cmu.edu/cmmi/translations/japanese/models/index.html

参考資料 SRSの目次サンプル IEEE Std. 830-1998の例「若手SEのための要求のまとめ方」の例マイクロマウスSW要求仕様書の例

SRSの目次のサンプル（IEEE Std.830-1998） • はじめに • 目的 • 範囲 • 用語定義 • 参考文献 • 概要 • 要求仕様の一般的な説明 • 製品の背景 • 製品機能 • ユーザ特性 • 制約 • 仮定及び依存性 • 要求仕様の具体的な説明 • 外部インタフェース • 機能 • 性能要求 • 論理データベース要求 • 設計の制約 • ソフトウェアの属性 • 要求仕様の段落構成 • 付録 • 索引

SRSの目次のサンプル（秋元、岡田著：「若手SEのための要求のまとめ方」より）SRSの目次のサンプル（秋元、岡田著：「若手SEのための要求のまとめ方」より） • イントロダクション • システムの目的 • システムの範囲 • 専門用語と略語の定義 • 参照 • システム概要 • 前提条件 • 開発の背景 • 開発の制約条件 • ユーザグループの定義 • システム要件 • 機能要求 • 性能要求 • 品質属性 • 制約条件 • 物理的条件 • セキュリティ目標 • 操作性 • システムのライフサイクルと維持管理 • 暫定仕様と依存性 • インタフェース • ユーザインタフェース • ハードウェアインタフェース • ソフトウェアインタフェース • 通信インタフェース

SRSの目次のサンプル（冨山がマイクロマウス制御プログラム開発用に作成したもの）SRSの目次のサンプル（冨山がマイクロマウス制御プログラム開発用に作成したもの） • 変更履歴 • はじめに • 対象範囲 • 参考資料 • 専門用語と略語 • システム概要 • ハードウェア仕様 • ハードウェア構成 • 基本機能 • システム状態遷移 • 使用条件 • 使用環境 • 機能要件 • 共通機能 • 探索走行機能 • トライアル走行機能 • 動作確認機能 • エラー処理 • 非機能要件 • 目標性能 • RAS（※）定義 • 開発条件 • 設計手法 • 開発環境 • RAS充実方針 • 主要マイルストーン ※Reliability（信頼性）, Availability（可用性）, Serviceability（保守性）の頭文字をとったもの。信頼性指標としてはMTBF（平均故障間隔）、保守性指標としてMTTR（平均修理時間）、可用性指標として稼働率を用いてシステムの信頼性を評価する。稼働率＝ MTBF / (MTBF + MTTR)

TSPi によるソフトウェア開発プロセス