【ＳＥ知識】要件定義とは
目次
１．記事を書くことになったきっかけ
この記事を書くきっかけになったのは、ふと疑問に思ったことがあったためです。
そもそも要件定義って何をどこまでやるべきなの？
現場によっては基準もばらばらで明確な線引きがされていない様な気がします。
なので自分なりにまとめてみようと思ったのですが、主観で書くと偏ってしまうので
以下の本を読んで勉強し直してみました。
この記事には私の考えも含まれていますので上記書籍の内容と異なる内容もあるかもしれませんのでご了承ください。
２．要件定義とは
そもそも、要件とは何なのか？
発注側の要求を実現するために必要な成果物、および、その成果物について
受注側と発注側で合意した納品検収条件である。
そのため要件定義とは上記を決める工程である。
３．要件定義でやるべきこと
要件定義は開発プロセスの中でも上位の工程になります。
要件定義をおろそかにすると後の工程である基本設計が立ち行かなくなるので
スケジュール遅延を発生させる要因になります。
それに設計工程で気づいた場合はまだ良いのですが、設計時に問題があることに
気づかず毎日定時で帰って順調な様に見せて実装やテストで問題が見つかると…
炎上間違いなしです！
ここで話を戻しますが要件定義では何をどこまでやるべきなのか？
まとめるべき要件は、機能要件、非機能要件がある。
■機能要件
・ＵＩ（User Interfaceの略、代表的なものに画面がある）
どのような画面が必要でどのような振る舞い（操作）をするのか詰めておく
・機能
必要な機能の一覧が網羅されており一覧化されていること
・データ
データパターンを整理した上でデータベースに必要な項目を網羅しており、項目単位で説明の資料が作成できていること
非機能要件については多岐に渡るため、WikiPediaのリンクを貼っておきます。
ＵＩと機能については普段の業務でもやるべきことを出来ていた感はあるが
データについてはここまで出来ていなかったような気がする。
要件定義の段階ではデータの流れを大まかに決めてデータパターンの整理は設計工程で行っていた節がある。しかしよく考えるとデータパターンが整理されていないと必要な機能の全量も挙げきれないため、後から機能追加になる可能性もある。
また、内容によってはデータベースに項目追加が発生する可能性もあり、ＤＢレイアウト変更を伴うとスケジュール遅延の要因になる。このことから要件定義の段階でデータパターンの整理までやるべきである。
４．要件定義で大事なこと
要件定義をする上で大事なことは何でしょうか？
予算と納期から出来るだけ顧客の要求を実現するに越したことはないが
たまに何でこんな画面の導線になっているのか？使いにくそうな画面だな～とか
思うことがあります。
発注者の要求をヒアリングして要件定義を行いますが中にはイケてない要求が出てくることがあります。その要求にどれだけの思いがあるのかヒアリングした上で、大して思いが無いようであれば代替案を提示してあげるのが重要だと思います。案は複数あるとなお良いです。捨て案①、本命②、本命案の一部採用版③といった感じで選んでいただくと本命が通りやすいです。
５．まとめ
要件定義は開発プロセスの中でも最重要と言っても過言ではないです。
これに失敗したプロジェクトの火消しは想像を絶するものがありました。
良い要件定義をして健全なシステム開発に務めていきたいです。
本記事だけでは要件定義の全てを伝えきれていないので要件定義について
さらに詳しく知りたい方は下記の書籍をおすすめします。
ではではこれにて失礼します。
