tanatiyo せお丸さんの動画をみて、要件定義について勉強しました。
ブログではメモ用にテキストだけを載せています。動画では図や絵なども出てきて理解しやすいので、動画をみながらの学習をおすすめします。
要件定義の進め方
・「やること」「やらないこと」を明確にする⇨「言った、言わない」を避ける
・細かい話（画面のデザインやDB設計など）はこの段階ではしない
要件定義書の書き方
今回、せお丸さんは、ネットフリックスのような動画配信システムを例にして要件定義書を書いていました。
要件定義書は主に大きく、3つの段落に分かれる。
「業務要件」、「機能要件」、「非機能要件」
業務要件
このシステムがどのような使われ方をしていくのかを書いていく。
「システムの概要」や「ユースケース（管理者、一般ユーザー）」など。
機能要件
このシステムにどのような機能があるかを書いていく。
「アプリの種類」「機能一覧」「外部システム連携」
「アプリの種類」では、WEBアプリケーションのみで、スマホアプリは不要と記述するなど、「やらないこと」をハッキリさせるのも非常に重要
「機能一覧」ではワードに書ききれないので、別紙エクセルにまとめるなどする。
機能一覧の書き方
列に「#」、「カテゴリー」、「機能」、「実装方法など」、「必須」、「備考」という項目を作って、「機能」１項目ずつに「#」で番号を管理している。
エクセルで管理しておくと、後々、列最後尾に「工数」や「スケジュール管理」などやりやすくなるので、エクセルでまとめておくのがおすすめだそう。
非機能要件
「インフラ構成」、「キャパシティプランニング」、「性能要件」、「可用性」、「死活監視」
「キャパシティプランニング」・・・システムを利用すると想定した人数や動画の本数などで、サーバーにかかる負荷を見積もる
「性能要件」・・・このシステムがどれだけの性能を発揮するのかを定義していく。
例）画面表示は2秒以内の表示を目標とする（応答率95%以上）
「可用性」・・・システムがどれだけ生きているか。
例）99.９％の可用性を目指す。そのため、Webサーバーは冗長化構成を取り、異常発生時は自動的にアクティブなサーバーへの切り替えを行う。
「死活監視」・・・このシステムが生きているか死んでいるかを監視。
例）ELBの標準機能による自動監視、自動切り替えを行う
まとめ
ざっくりと動画をみながら要件定義と要件定義書の書き方についてアウトプットしてきましたが、要件定義書は、もっと細かい項目に分けて書くこともあるそうです。
ウォーターフォール開発時の注意として、後戻りできない点がある。
そのため、要件定義の段階で漏れがないように、きちんとドキュメントに書き起こしておく必要がある。
また、設計書に挟み込む図には決まった書き方がある。
UMLという（→別記事で書きました。）
動画内で紹介されていた記事が以下の通りです。
こちらの記事も読んで勉強させていただきたいと思います！