システムやアプリケーションの要件定義、設計から実装、完成まで

はじめに

普段システムやアプリケーションを作るのに、どういう手順でやるっけかなーというのを書き出してみた、というものです。

必ずしもこの通りにすればうまくいく、というものではなく、一例だと考えてください。

流れ

大雑把に次のような流れになります。

  1. 何をしたいのか、まとめる(企画、要件定義)
  2. 要件を満たすシステムの入力や出力の詳細、データの流れやシステムの処理をまとめる(仕様策定)
  3. 要件、仕様をどうやって実現するのか考えてまとめる(設計)
  4. 設計に対応する実装をする、システムを構築する(実装)
  5. 実装、構築して出来上がったものが、要件や仕様を満たしているか確認する(試験)
  6. 完成

各工程で、アウトプットしたものを後工程で使ったりします。

1. 何をしたいのか、まとめる(企画、要件定義)

f:id:nullpobug:20160731235726p:plain

システムやアプリケーションに限らないですが、そもそも何をするのか決めていないと、始まらないので、やりたいことをまとめます。

システムが解決したい課題は何か、文章や図でまとめます。

次のようなことを書き出してみればいいです:

  • どういう背景(ストーリー)があってシステムを作るのか
    • システムが無い場合、どような課題があるのか
    • 既存の作業や仕組みを置き換えるのであれば、その流れ
    • 誰がシステムを使うのか
  • システムでは何をするのか
    • 課題のうち、システムが扱う範囲、扱わない範囲
    • システムに入力されるデータは何か
      • 人間の操作、外部のデータ、システムによって取得されるデータ
  • システムはどのぐらいの性能が必要か(性能要件)
    • 利用者の数(延べ人数、同時に操作する人数など)
    • 扱うデータ量(入出力のデータ量、保存するデータ量)
    • システムの処理時間(入力から出力までの時間、画面の応答速度)
  • システムはどのような環境で動作させるか(動作環境の制限、要件)
    • 特定のハードウェアやクラウド、プラットフォームを使わないといけないなどの制約はあるか

この工程でのアウトプット:

  • 企画書、要件定義書などに相当する資料(読んだら何をしたいのかがわかる資料)

ポイント:

  • 長い文章よりも、箇条書きで整理されたものがわかりやすい
  • 文章だけではなく、図もあるとわかりやすい
  • 具体的な画面のイメージや処理の流れがあるなら絵を書いておくとよい
  • やりたいことがまとまらない、という場合、課題がはっきりしていない可能性があります。現状何が問題なのか、整理するとよさそう。

2. 要件を満たすシステムの入力や出力の詳細、データの流れやシステムの処理をまとめる(仕様策定)

f:id:nullpobug:20160731235723p:plain

前工程で何をしたいのかを明らかにしたので、システムが扱う部分をもう少し具体的にします。

次のようなことを書き出してみればいいです:

  • システムを機能毎に分けたもの
    • 入力、出力、処理など
    • 機能数が多い場合は大中小などのまとまりを作って、ツリー状にして整理するとわかりやすい
      • 最上位階層が10~20程度になる場合は、やりたいことが多すぎるので、サブシステム化(別のシステムに分割して、システム間で連携させる)も検討したほうがよい
  • 入出力されるデータのフォーマット
    • 各機能毎の入力と出力
      • 外部のデータを取り込むor送信する、ファイルを読み込むor書き込む、データベースを読み込むor書き込む など
    • 利用者の具体的な操作(何を使って、どのように操作するのか)
    • 画面上の入出力

この工程でのアウトプット:

  • 仕様書に相当する資料(各機能と入出力がわかる資料)

ポイント:

  • 箇条書きを使って、できるだけ簡潔に説明する。仕様が複雑だと後の工程が大変です。

3. 要件、仕様をどうやって実現するのか考えてまとめる(設計)

f:id:nullpobug:20160731235725p:plain

前工程で機能と入出力を明らかにしたので、この工程では具体的にどうやって作るのかを考えます。

機能、入出力をつないで、1つのシステムとして整合性のとれた状態にする必要があります。

次のようなことを書き出してみればいいです:

この工程でのアウトプット:

  • 設計書に相当する資料(各機能毎に、入力から出力までの間に何をするのか、どのように構築するのか、がわかる資料)

ポイント:

  • 箇条書きや図を使って説明する。
  • 実装や構築が困難な設計を避ける(後の工程が大変になります)
    • 必要以上に複雑にしない(要件を満たす以上のことは、実装が終わってから余力でやるぐらいのほうがいい)
  • 実装に着手するには、すべての機能の設計が終わってないとダメ、ということはないです。並行作業で進められることもあります。
    • しかし、並行作業で進めると、「実装中の機能に設計変更が必要になった」というのもよくある話です。システム全体の整合性のためにも、設計は早めに終わらせといたほうがよさそうです。

4. 設計に対応する実装をする、システムを構築する(実装)

f:id:nullpobug:20160731235722p:plain

前工程の設計に従い、システムの実装、構築をします。

設計が適切であれば、実装は楽に進められます。

この工程でのアウトプット:

  • 必要な機能が実装されたシステム

ポイント:

  • 設計や仕様に不備がある場合は、設計、仕様にフィードバックしつつ、実装を進めていくとよさそうです。

5. 実装、構築して出来上がったものが、要件や仕様を満たしているか確認する(試験)

f:id:nullpobug:20160731235724p:plain

実装が終わったら、最後に要件や仕様を満たしているのか、確認(試験)をします。

試験の方法は、要件と仕様を元に、試験項目書を作ってテストしたり、ざっくり動かしてみて問題なかったらOKとしたり、プロジェクト毎に異なります。

試験の結果、問題がある場合は修正して再試験します。問題がなければこの工程は終了します。

この工程でのアウトプット:

  • 試験結果
    • 問題の有無(要件や仕様に沿ってない場合は問題がある。)
  • 問題を修正したシステム

ポイント:

  • 試験項目書をつくる場合は、試験項目書に記入した結果がアウトプットとなる
  • 問題が致命的かそうではないか、などカテゴリ分けすると、わかりやすい

6. 完成

f:id:nullpobug:20160731235727p:plain

試験が完了したら、システムは完成となります。

必要であれば利用者向けのドキュメントを作成したり、納品物にまとめたりします。

まとめ

企画、要件定義→仕様策定→設計→実装→試験、という流れになります。

書いてから思ったけど、ウォーターフォール・モデルですね、これ。

自分の中で、開発の手順を意識できていれば、次に何をすればいいのかわからず戸惑う、という状況は減るのではないかと思います。

記事中のイラストは、いらすとやのものを使ってます。