4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

要件定義について

Posted at

はじめに

これまで、システム開発を依頼する側として、何度も要件定義を固める工程に接してきたのですが、今回、初めて、システムを作る側に立って、要件定義書をまとめることになり、勉強したことを記録し、次回以降に役立てたいと思います。

そもそも要件定義とは?

・用語説明としては以下のサイトによると、

要件定義とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などのを明確にしていく作業のこと。いわゆる上流工程の一部で、実際の開発・実装作業を始める前に行う作業の一つである。
https://e-words.jp/w/%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9.html

と定義されています。

・つまりは、システムを開発し、運用するまでの過程の中で、システムを決める重要な基盤だといえます。確かに、社内での課題や要求をまとめた後、システム会社さんと連日、打ち合わせをし、どういう機能や画面を作るか、画面の色やボタン配置、タブキーでのフォーカスが動く順番など様々なことを決めてました。(これが機能要件にあたるのだと思います。) また、その時にバックアップの時間帯、回数や障害発生の通知・復旧手順、処理の反応時間なども決めました。(こちらが非機能要件です。)

・ウォーターフォール型で開発を進める方式の場合、この工程1回で、後に続く設計、プログラミング、テスト、運用すべてが決まるので、取りこぼし(発注側だと要求忘れ)が無いようにしなければ、また最初からやり直しという恐ろしい事態にもなりかねないのです。 また、要件定義段階で、機能に入れないとした項目について、テストしてみてやっぱり入りますということもあるかもしれません。

要件定義書をまとめる手順

・システム開発を進めるにあたって、実装する機能、性能を明確化した要件定義書を作る手順については以下に挙げる流れで進めていきます。

1)発注者側へのヒヤリング (現状の把握とシステム開発後の業務フローを作る。)
  • まず、現状の業務がどのように行われているかを分析し、問題を抽出した上で、新たに何を実現すべきかを決めるため、相手へヒヤリングを行います。
  • よく知っている領域や以前に同様のシステム開発の経験がないのであれば、並行して、業界用語や慣習、さらにはその企業独自のルールなどの理解を深めておく必要があります。以前、開発を依頼したとき、システム会社さんが連日のように部署ごとに通い詰めて、業務内容の聞き取りをされていました。
  • ヒヤリング後、システム導入後の新しい業務フローを作り、発注側とブラッシュアップしていきます。
2)要求を細分化・切り分けをして、システムでどう実現するかを決める。
  • 1)でまとめた現状、課題や業務フローを実際にシステム化するにはどうするか(手段を決めるに近い)をまとめていきます。
  • 上がってきた要求すべてを実現できるとは限りません。システム化しなくても業務の段取り・方法を変えるだけででできるものもあると思います。この段階で、やること、やらないこと(要望について100%までは難しいがある程度までは実装する)もしっかり切り分けておくことが重要と考えます。
3)2)で決めたシステム化の方向性を基に、具体的に実装する機能を決める。
  • これまでの手順で固まった内容をシステム化するにあたって必要となる機能を具体的にまとめていきます。
  • システム全体に共通する機能、個々の画面や帳票の機能などに分けて検討し、まとめていきます。例えば、システムを外出先でも使いたいという要望に対して、ノートパソコンなのかスマホなのか、外出先では特定の画面(機能)しか使わないのか、すべての機能を使うのか、専用のアプリを別に作る必要があるのかと検討した上で、具体的な機能要件をまとめていきます。
4)3)以外のセキュリティやデザイン、処理速度、保守・運用などについて要件をまとめる。
  • システム化するにあたっての機能を決めた後は、利用者側が、この『機能』以外にシステムに求めることをまとめていきます。
  • 稼働時間やバックアップの方法、障害発生時の対応、セキュリティ、保守・運用などの項目を決めていきます。一般的にここで取り決めたことは、実現すればするほどクライアントの満足度を上げることができるとされています。
    ここで取り決める項目については、下表のようなものがあります。
分類 主な要件項目
①可用性 ・障害や災害時における稼働目標
②性能・拡張性 ・画面レスポンス
・データ増加
③運用・保守性 ・稼働時間
・データバックアップ
・システム監視
・計画停止
・サポート体制
④移行性 ・移行スケジュール
・移行方法
・移行データ
⑤セキュリティ ・認証機能(ログインなど)
・機能制限
・データの暗号化
⑥環境・エコロジー 耐震や温度、湿度、騒音など
(IPA 非機能要求グレードを参考)

最後に

・実際に、要件定義をまとめていく中で、ある程度知っている領域だとはいえ、システムへ落とし込むことや今回見送る機能について代替案として何かできないかなどを考えながら進めるのに時間がかかりました。更に、相手に図など資料を作って、説明するとなると・・・・。 

・今後、勉強したこと、上手くいかなかったことなど、随時、書き足していこうと思います。

4
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?