【 無料 テンプレートあり 】要件定義書におけるシステム化要件

2021/12/10

要件定義はシステム開発の上流部分を担い、非常に重要な業務となります。

システムの全体像を把握しなければならないため、難易度は高く、責任も大きいです。

しかし、その分だけ下流のエンジニア職種と比較して平均年収は高い傾向にあります。

PG の方でキャリアの積み上げとして別のプログラミング言語を勉強される方が多いですね。

ですが、上記の理由により自分の市場価値を上げたいならば、上流工程を勉強するほうが確実に自分の市場価値はあがります。

また、今まで下流工程しか経験していなかった PG が上流工程を勉強することで、「システム全体像を考えてから実装までできる」ようになります。

つまり、全体視点を持ちつつ開発ができるようになります。

今回は要件定義における「システム化要件」についてエントリーします。

 
現役 PM の僕が利用している要件定義における「システム化要件」のテンプレートを公開します!よかったらどうぞ!

以下のリンクを「右クリック」> 「名前をつけてリンク先を保存」で Excel ファイルをダウンロードしてください。
 
要件定義書(システム化要件)

 

INDEX

 

1)要件定義の重要性

例えばスクラッチ開発の流れは、基本的に以下のようになります。

打ち合わせ → 要件定義 → 画面デザイン(UI)→ システム開発 → チェック・デバッグ → テスト運用 → 本番公開 → 運用 → メンテナンス・拡張

このなかで、特に重要なのが要件定義のステップです。

要件定義とは、どんなシステムを作りたいか を開発会社に伝える工程で、ここでの依頼をもとにシステムが作られていきます。

この際に曖昧な表現で希望の条件を伝えてしまうと、後々作り直しとなり、費用がかさんでしまうのです。

これを避けるために、口頭だけで伝えるのではなく、紙媒体を用いるなどして正確に情報を伝えるよう心掛ける必要があるのです。

 

2)要件定義の成果物

要件定義とはクライアントの要望と、その要望をどのようにかなえるかを文章としてまとめた物となります。

システム開発を進める上で必須の工程です。

個人的によく見る要件定義の成果物は以下になります。

  • 1)システム化要件
  • 2)業務フロー
  • 3)業務処理概要
  • 4)非機能要件
  • 5)サービス移行概要

1)システム化要件

システム開発の初期の工程で定義されます。

情報システムに求められる機能や性能などの要件になります。

システムが何をどのくらいできなければならないか を定めたドキュメントです。

今回は「システム化要件」について掘り下げていきます。

 

2)業務フロー

現場で行っている業務のプロセスを可視化しるために作成するフロー図のことです。

業務プロセスを「見える化」するためのツールになります。

一般的には「スイムレーン」と呼ばれる枠で部門を表現し、業務を記号で表したうえで各業務を矢印でつなぎ、業務プロセスを図式化します。

業務フロー図の作成についてはすでにエントリーしています。よかったらご参照ください。

 

3)業務処理概要

業務フローよりもっと詳細に、各機能ごとの「データの流れ」や、「サービス遷移」「処理概要」などを定義していきます。

 

4)非機能要件

非機能要件では、情報システムやソフトウェアの開発に際して定義される要件のうち、機能面以外のもの全般を指します。

機能要件はシステム化要件にて「開発対象一覧」の項目として定義します。

非機能要件は資料として分けたほうがわかりやすいため、別紙として作成します。

具体的には性能や信頼性、拡張性、運用性、セキュリティなどに関する要件を定義します。

 

5)サービス移行概要:

受入テストを終えたシステムを受入先のシステム環境に対してリリースするために必要な計画・準備・切替・確認など一連の作業を定義します。

システム開発の規模に比例して作成する資料は多くなりますが、逆に規模が小さければ資料も少なくていいでしょう。

 

3)システム化要件とは

・システム開発の初期の工程で定義される。
・情報システムに求められる機能や性能などの要件を定義する。

要件定義書における「システム化要件」に記述する項目としては

1)目的
2)前提条件
3)システム概要
4)開発対象一覧

明確な縛りはありませんが、この辺りの項目を抑えておけば問題ないと思います。

クライアントとコミュニケーションをとりながら要件を定義すればいいでしょう。

 

4)要件定義書は何で作成する?

要件定義書などドキュメントの作成に法的な縛りはありません。

常識で考えると、要件定義ができる(双方で認識の相違が発生しない)アプリケーション(表現方法)を優先すべきです。

(※むしろアプリケーションに拘って、要件が定義できなければそのほうが問題です。)

各アプリケーションごとに得意な分野と不得意な分野があるので、「どういうドキュメントが作りたいか?」を考えて作成するといいでしょう。

各アプリケーションの特徴は以下になります。

 

Word

【メリット】
ドキュメントを作るために存在するだけあって隙が少ない。

【デメリット】
画像や図形の取り扱いが下手くそ。

 

PowerPoint

【メリット】
画像や図形の取り扱い上手いので、絵(概要図など)を描いて説明する場合は用途が合う。

【デメリット】
文章を書かせると弱い。

 

HTML(+Markdown )

【メリット】
機械で動的に作るのが得意。Gitなどで世代管理が出来る。

【デメリット】
時間がかかる。多くのファイルが密集するのでファイル管理や技量(エンジニアとしての才能や技量)が必要。

 

Excel

【メリット】
扱えるSIerさんが多い。営業などの非エンジニアの人も得意。

【デメリット】
画像や図形、文章の記述が弱い。

個人的な感覚だと要件定義や基本設計、詳細設計は Excel ベースが非常に多いです。

恐らく、多くの SIer や SE が参考にしている IPA(独立行政法人 情報推進機構)のサンプルの要件定義書や基本設計、詳細設計が Excel ベースで作成されているからだと思われます。

 

5)システム化要件の無料テンプレート

現役 PM の自分が Excel 方眼紙でシステム化要件のテンプレートを作成しました。

共有しますので、よかったらどうぞ。

以下のリンクを「右クリック」> 「名前をつけてリンク先を保存」で Excel ファイルをダウンロードしてください。
 
要件定義書(システム化要件)

【 作成ポイント 】

基本は Excel で作成しています。

ただし「概要図」はパワーポイントで作成し、それをスプレッドシートに貼り付けました。

やはり、Excel やスプレッドシートでは、「図を描く」という点においては苦手としていますね。。

 
以上です。

仕様書・設計書作成 おススメ教材(by Udemy)
動画でプログラミング学習!ドットインストール、Schoo、Udemyのどれがいい?
 
Udemyを使ったLaravel学習方法

手を動かして学ぶITプロジェクトの資料作成!システム開発のドキュメンテーション技術と成果物テンプレート

なかなか学べる機会の少ないITプロジェクトの資料作成。プロジェクト計画から要件定義、設計、テスト、移行、運用まで、いつ、何を決め、どんな資料を作ればいいのか、開発現場のリアルな視点で徹底解説。
4.2(2314)

 
 

本庄マサノリ

仕事で Laravel を使っています。気づいたことや新しい発見など情報を発信していきます。問い合わせはこちら

>> Twitter をフォローする

 

-実践知識