要件定義の始まりは要求事項の整理から
要件定義の項目
・背景/目的/目標：開発の目的を明確にする
・成果物概要：第三者でも成果物がイメージできるものを図示する
・動作環境：アプリケーションの動作環境を記載する
・ユースケース：重要なユースケースを挙げる
・機能要求：要求事項を実現するための機能を検討する
・入力/出力要求：アプリケーションの入力、出力を明確にする
・接続性要求：連携するアプリケーションがあれば記載する
・ソフトウェア要求：保守性、信頼性、拡張性の目標とするレベルを定義する
・セキュリティ要求：セキュリティの側面からの対応内容を検討する
・スケジュール要求：要求されるスケジュールを記載する
要件定義書を書く時の注意点
機能要求の整理
要求の最小単位を明確にして構造的に記載することで、
下記のようなメリットが得られます。
・要求全体の理解がしやすくなる
・石器フェーズでソフトウェア構造を検討するときにプラスになる
・要求が追加、変更になった場合に影響範囲がとらえやすくなる
曖昧さを排除する
ある処理結果までの時間に対する要求であれば、
「処理時間は○○秒以内」と愚弟的に記載する
非機能要件にも注意する
非機能要件に対する対応策をしっかりとまとめておく！
設計はしない
要件定義とは要求を分析し、
アプリケーションの外部の振る舞いを検討する作業
要件定義の段階では設計の自由度を
残しておくことがベストプラクティス
依頼者からの機能要求を無批判に受け入れない
設計にかかわるくらいの「何をどうする？」という機能要求がでたとしても、
その背景、課題、解決方法など、
ヒアリングを行い要件定義書に記載する。
よりよい要件定義のための一工夫
プロトタイプを活用する
画面仕様の要求の確認に対してのプロトタイプは有効
最終的なアプリケーションのような振る舞いをするプロトタイプの作成には
準備に時間も工数もかかるため、
画面遷移と各画面のレイアウトのイメージがわかる資料を簡単に作成し、
紙芝居的な動きを見せるだけでも十分に効果がある。
おわりに
この記事は、
自分なりに要件定義の理解を深めようと、
情報を咀嚼した残骸のようなものです。
ためになるひとが一人でもいればそれでいいと思って書いています。
最近私の記事に、
フォローやいいね、キープなどのアクションが
少しずつ見られるようになってきました！
そういった皆さんの反応が、
とてもうれしいのでまだまだ頑張っていきます。
何卒応援よろしくお願いします。