要件定義～システム設計ができる人材になれる記事 - Qiita

ご要望が多かったので要件定義〜設計に関するUdemy講座クーポンをご用意しました。 ぜひご活用ください＆高評価いただけると嬉しいです m(__)m ■入門編： ■応用編： はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 につ

[turanukimaru]

良くも悪くも伝統的なやり方。これが出来れば最悪でもgdgdにはならない。何を作ればいいのかお客さん自身が実のところ分かっていないってのがシステム開発の最大の難所なのでやり方は有れどなんとか形にするしかない

[oceantug]

再掲か。要件定義の成功条件は、①発注者側に業務だけではなくITにも詳しい人間を１名、②受注者側にITだけでなく業務にも詳しい人間を１名準備すること。この二人を個室に閉じ込めて差しで要件定義をやらせること

[yojik]

この文章は、はじめよう！要件定義 という本の一部の内容をまとめたもの　(なぜか参考文献を提示していない)

[carrier_pigeon]

非機能要件蔑ろにしすぎ感があるなぁ。性能、セキュリティ、メンテどうするとかリカバリとか。オペレーション重要。むしろそこに見積もり載せる説明できないと、機能要件だけで金取るとあとで死ぬ。

[findup]

レガシーかもしれないけど、今ドキの開発なら単にプロダクトオーナーがこのあたりをお膳立て済みだから開発者が意識しなくて良いだけになってるからでは。誰かがやらないといけないことだと思うけど。

[otihateten3510]

最近ますます要件定義フェーズが存在感をなくしていると思う。要件定義工数ってちゃんと取れるんだろうか？工数取れないとこういうことできないんだよね。　まあ俺の観測範囲の問題か。

[tossy_yukky]

とてつもなくウォーターフォール臭がするけど、一人で作るんでも脳内でこれやってるわけだから、これができないとダメってのはそうなんだろな。

[halix]

うっ…WordかExcelで作られた要件定義書…頭がっ…！

[lorenz_sys]

"のどが渇いた時に「飲み物買ってきて！」とお願いするでしょうか？" システム開発のお客さんは「なんか買ってきて！」とか「ロマネコンティ買ってきて！千円しか出せない！いくら飲んでも減らないやつな？」とか。

[testedquality]

これをお金出す人も一緒に作って理解するのが、一番確実にシステムができる方法だと思ってる。そして往々にして早く安くなる。コード書けなくても欲しいものの判断はしてくれ。使うのはあなただ。

[pmint]

「満足」ではなくお金を貰える条件。要望と要求は一緒。要求→要件は、お互いに相手側の事情を知ってる人材が詰めていく。機能設計の画像6枚はいまいち不正確。

[axnsword]

この文章は、『はじめよう！要件定義』という本の一部の内容をまとめたものと思われます　(なぜか参考文献を提示していない)。よい記事だが、信頼できない。

[jinjin252525]

要件定義

[cman8]

ウォーターフォールの基本の流れ。

[hidecharo]

Software development process.😊

[style_blue]

そのうち必要になるかもしれないのでぶくま。わし発注者側にいるIT解る人なので作る方は「やりたくない」を「出来ない」で誤魔化せなくてたいへんそうだったなｗ やる事よりもやらない事を決めるね、なるほど。

[hachiame]

要件定義についてわかりやすく解説されていて理解しやすかった。システムの全体像を掴むためにも画面設計×機能設計×データ設計を合わせて考えることでより良い設計になっていくプロセスが見れて参考になる。

[password1234]

このスパムアカウントまだやってるのか…

[nyop]

絶対この筆者、まともに要件定義やったことねぇ。“What（業務フローや機能要件・非機能要件）はエンジニアではなく、開発側の中でも「営業マン」や「セールスエンジニア」が対応する仕事である傾向が多い”

[sawasawa12]

あとで必ず読む

[hdampty7]

発注側のテクニックとして技術分かる人間がいない場合はまず要件定義だけ発注するとかすればよいの。どうやって営業とか実務に携わらない部外者をプロジェクトから排除するか、それが重要。

[clash_m45]

なかなか纏まっていて良い

[kyorecoba]

あとで

[salon_hiyake]

使う人=作る人、の時代だよ。ここに書かれてることぐらいは、末端の入力係でも知っておこうね。

[fkatsya]

木っ端SIerの感覚でいうと、やらないことをちゃんと決めることが要件定義では重要だと思っていて、やることを決めていくのはどっちかって言うと基本設計以降なんですよね。使う脳が全然違う。

[y_maeyama]

例えばWebアプリなどを開発するに当たって、コーディングの前に何をすべきかイメージできていない新人さんに刺さりそう。簡潔にまとまっているので分量が多くて挫折することもなさそうなのが良い。

[IGA-OS]

頭にイメージを描けない発注者が多いんだよね。発注側になることも多いから自戒を込めて

[evil07]

要望・要求・要件のグラデーションは絶対に発生するんだけど、ごっちゃにしちゃうことあるんだよな

[advancedbear]

解説図が丁寧でわかりやすいのが良いね

[miho-satoh-satomi]

要件定義

[piroshiii]

例題のER図はヤバい。購入履歴に価格や商品名は入るべきで、その時点のスナップショットであるべき。商品値下げしたら履歴から追えないぞ。

[kdmsnr]

羽生さんの本のパクりっぽいので、参考文献に載せたほうがよさげ（Qiitaだから仕方ない感はあるけど。。。）

[kat21]

ほぼ網羅されててとても良い。あとは非機能要件があるともっとうれしい。

[frozen_faithjp]

“まとめる”

[pikio]

端折ったWhatのとこ、重要だと思うけどな

[masakitk]

患者さんが自分の病気の病名と原因と対処法を知らないように、お客さんが自分が欲しいものを知っている前提で進めてしまうと大体あとでもめる。

[braitom]

実装の前に必要ないわゆる上流工程について解説した記事。要件定義の必要性やプロセス、画面設計/機能設計/データ設計などの基本設計の作り方などがまとめられている。

[azuk1]

この辺は自分の経験を通して形にしていかないといけないので、触りだけ教育されて現場に放り込まれた新人PMの案件は大体火事になる。もっと抽象度減らしていかないと誰でもできる仕事にはならないんだよな。合掌

[yuki_2021]

重要な話だよな。最近勉強したいと思ってる。