これは、プログラミングの初心者でまだどこにも内定や、案件を獲得できていない、初学者が勉強したばかりの要件定義について仮想と妄想で考えた要件定義書です。
色んなご指導、意見いただけると嬉しいです。

・なぜやろうと思ったのか？
エンジニアには文章力や単純に伝える能力は必要とのことで。

・参考資料は？
Backlog/ブログ
(参考)　要件定義とは何？スムーズな進め方や成果物(要件定義書)についても解説

##1.要件定義とは何か？
クライアント、お客さまの要望を叶える為にまとめた文章
###1.1.要件定義はプロジェクト成功の鍵となる
クライアントの要望を徹底的に聞き、引き出してから開発が始められる。
要望と解釈に齟齬があっても工程が進むごとに無理が出てきてしまうのでキチンと決めること、でも時間かけすぎても納期に間に合わなくなるからほどほどに。
###1.2.インプットの工程も大切に
多くの依頼は既存の物の改良であることが多い。既存のシステムや現状を確認させてもらうこと。
RFP(提案依頼書)などを確認したり、保守担当から調査するなどしましょう、この、今の現状を把握することを「インプット」といいます。
###1.3.成果物は要件定義書
要件定義の最後はあくまで書類にまとめること、この書類は要件定義書といいます。
内容はは第三者が見ても分かるように且つ機能は詳細に、技術者でない人、専門知識がない人にもわかるように伝わるようにかくことを意識すること。
そして、クライアントにきちんと確認をもらいましょう。
##2.要件定義書に記載すべき必須項目
###2.1.システムに関する項目
実装するシステムについて
####2.1.1. 1.システムの概要
どのような機能を備えたシステムなのかについて説明します。
業務要件はエンドユーザーの視点で、システム要件はエンジニア視点で作られます。
例）サイトに「商品購入」ができる機能を実装して欲しいという要望の場合、業務要件は「商品購入」で、システム要件は「カートに商品を入れる」とできます。
####2.1.2. 2.システムを導入する目的
システムを導入して、どんなことが実現できるか説明すること
####2.1.3. 3.システム導入後の業務フロー
システムを導入すると、業務フローがどのように変化するのかについて書きます。
例）自動釣銭機を導入する要望の場合、新しくそれを導入すると、これまでとはレジ打ちの方法が変わります。このいった実際の変化について書きます。
###2.2機能要件に関する項目
クライアントご求める機能のこと。
技術側にとってのゴール。データなどシステムが処理可能である内容についても書きます。
###2.3非機能要件に関する項目
機能以外に求められるもの、保守やセキュリティなど。こちらのほうが非機能要件より難しい場合が多い。
##3.スムーズに行える要件定義の手法
###3.1既存の業務フローとシステムについて知る
色んな所に解決すべき問題が出てくるので、できるだけ工数を少なく、問題を理解し解決策を練って、スピーディに行うこと
###3.2要求定義書と要件定義書のすり合わせをする
クライアントの要求と開発側の要件にズレができないようによーくすり合わせること。
###3.3丁寧な要件定義書を作り共有する
実際はお互いの都合や時間の問題もあるので、そう何度も何度もとはいかないので、必要最低限の回数で、イメージしやすく、誰が見ても同じ解釈になる文書にすること。
###3.4担当者を明確にしておく
プロジェクトの担当を決めておきましょう、あとで曖昧にならないように。
クライアントがやっておくべきことも開発側でやってしまうことも少なくないとのこと。
##4.良い要件定義書の必須条件
###4.1専門知識がなくても内容が分かる
誰が読んでもわかる文章で！
###4.2問題の解決策が記載されている
要望、願いを叶える「答え」の書かれた文章で！

##まとめ
エンジニアも文章力が求められるということですね。
これからもこういった参考書類をまとめたものを書いてみたいと思います。
間違っている所などございましたらどしどしご指摘ださい。
ありがとうございました。