開発プロセスを改めて理解する（要求と要件）

はじめに

先日、先輩から「ソフトウェア工学」というものを教えていただき学び始めました。
情報系の学部を出ていたり、新卒でSIerに入られた方は馴染みがあるかもしれないですが
個人的には馴染みがなく、、改めて学んで行くと
「エンジニア1年生の最初に知っておきたかった、、」　というものも多かったです。
個人的な備忘録的なものになってしまいますが、印象に残ったものを書いておきます。

今回はこちらの2冊を参考に書かせていただきました。
①「実践ソフトウェアエンジニアリング」

ソフトウェアエンジニアリングの様々な手法がぎゅっとまとまっています。
こちらが分厚い。そして字が小さい。読み切るのに気合が必要でした。
一度読んだら手元に置いておいて、見返す用としても良い気がしています

②「ずっと受けたかったソフトウェアエンジニアリングの新人研修」

新人研修とあるぐらいなので、基本のき、実践ソフトウェアエンジニアリングよりは深さはないですが、読みやすかったです。
こちらを読んでから「実践ソフトウェアエンジニアリング」読んだ方が読みやすさは違うかなと思います

開発プロセスについて

様々書き方はありますが、ざっくり以下の流れかと思います。

企画/仮説立案 → 要求定義/要件定義　→ 設計（外部設計・内部設計）→　製造　→　テスト　→　運用　→　効果検証

余談ですが、、エンジニアとして転職するまでは、もはや機能開発＝製造のイメージでした。
当たり前ですが、家を建てるときに建て始めないのと同様に、
1つのシステム、機能を作るにも当然実装までに設計図が必要です。
そして作って終わりではなく、その後運用、保守も必要です。製造は開発プロセスの一部でしかないなと改めて。

要求定義と要件定義

ごちゃごちゃになりやすい、要求と要件について。
主語（顧客なのか、システムなのか）を明確にすることで個人的にはスッキリしました

• 要求定義
  「顧客が」 やりたいことを書いたもの

  • 機能要求と非機能要求について
    • 機能要求
      システム化する手順を実現するもの
    • 非機能要求
      機能要求以外にシステムが兼ね備えるべき条件
      日本情報システム・ユーザー協会（JUAS）の「非機能要求仕様定義ガイドライン」が網羅性が高かったです。

• 要件定義：
  「システムの」 要件。何を作るのか、の答えに相当するもの
  ここでは過不足、矛盾がないようにしておく必要があり、また実現性もここで考える

  • 要件定義書に何を書くべきか　規模によりけりだと思いますが、以下があがっていました。
    • 背景：システム対象業務の背景や現状
    • 課題：システム化対象業務の課題
    • 目的・方針：システム化する目的、課題の解決方針
    • 概要：概要や特徴
    • 機能：システムが持つ機能（機能要求・非機能要求）の概略
    • システム化の範囲：システム化する業務や機能の範囲
    • ユーザーインターフェース：システムで用いるユーザーインターフェースのイメージ
    • システム構成：システムのハードウェア、ソフトウェア、ネットワークの構成概要
    • 導入・移行計画：導入時期や既存システムからの移行方法など
    • 運用保守：運用、保守の体制や方法
    • 用語の定義：システムで使用する用語の説明
    • 工程計画：設計、開発、テストなどの主要な作業の完了時期
    • 体制：人的体制や作業環境
    • 成果物：納入する文書やプログラムの一覧

終わりに

普段は特定の技術（という言い方であってるのか）を学ぶことが多いのですが
（最初にこれを体系的に学んでおけば、、と思う部分もありますが）
機能開発はこのように進めていきますという一連のプロセスを改めて理解することができました。
また開発モデルについても、アウトプットできたらと思います

参考文献