エンジニアとしての問題解決思考 - Qiita
みなさん、普段エンジニアとしてどんな仕事をしていますか？ 新規開発？保守運用？色々あると思います。 さて、どんな仕事をしていても開発要望や、開発依頼などがお客様、または企画・開発からやってくると思います。 例えば、「管理画面にxxでも検索出来る機能を作って欲しい」とか。 このような依頼にどう対処しているでしょうか。 A. すぐに要望に答えて作る B. 今の仕事を終わらせてから作る C. 開発リーダーと調整して、都合の良い時に作る D. なぜそれが欲しくなったのかを聞く 依頼側からすると、A~Dの順で「仕事が早くて良い人だ」という評価をするでしょう。 果たしてその問題とは何か？ 我々エンジニアの存在意義は、欲しいものを作る事が仕事ではありません。 (と、私は考えてます) あらゆる問題を「技術」という道具を使って解決する人間です。 まずは、依頼や要望が来たときに、それが「なぜ問題か」を考える必
読んだ「成功する要求仕様 失敗する要求仕様」 - モノラルログ
「成功する要求仕様 失敗する要求仕様」アラン・M・デービス 成功する要求仕様 失敗する要求仕様 作者:アラン・M・デービス日経BPAmazon 読んだ。いわゆる要件定義・要求定義に関する本。帯に「デマルコ絶賛！」とあり、表紙の感じからも「ピープルウェア」など一連のシリーズものの扱いなのかも。2006年初版ということでけっこう古いんだけれども、自分は最近知った。 原題は “Just Enough Requirements Management” ー ちょうど十分な、要求マネジメント。「ちょうど、十分な」というところがミソっぽい。 雑感 (雑な感想) いや、良くまとまってるなーと思った。この本では、要求を「導き出し」、「トリアージし」、「仕様化」、という流れからの「変更を管理せよ」となっている。 問題解決やビジネス成功のために大事なことは、 ユーザー視点を理解する 時間やリソースに都合のつく問
良いユースケースを書くための発想法
システムの要求仕様を決めるのに、ユースケースを使うことがよくあります。 しかし、ユースケースは上手く書けない、何を書けば良いのか分からない、という人も、少なくありません。 たいていのユースケースは、アクターが１人２人いて、アクターが行える操作がいくつか丸で描かれて、それらが線で結ばれているだけの、とてもシンプルなものです。しかし、シンプルすぎて、何の役に立つのか分からない、という人もいます。 役に立つユースケースを書こうとして、細かいことまで書き込みすぎてしまう人も良く見かけます。しかし、それは誤りです。 ユースケースは何のために書くのでしょうか。ここでは、ユースケースの目的をはっきりさせて、良いユースケースを書くための考え方を紹介します。 開発者は、細かいことまでユースケースに書き込みがち Design Wave Magazine 2007年5月号別冊付録「組み込みシステム開発者＆LSI
要求工学を学んで健康的なエンジニアライフを送ろう - Qiita
はじめに ソフトウェア工学とそれがもたらしたライフサイクルモデル、及びアジャイル開発についての学習を進めています。 参考：ソフトウェア開発プロセスを学んで健康的なエンジニアライフを送ろう その学習と並行して、要求工学というものも学習を進めているので、学んだことと私が吸収して噛み砕いたものをアウトプットしておきたいのです。 間違いや誤解、助言などがあればコメントや編集リクエストをいただけると大変助かります。 目次 要求工学 要望、要求、要件の違い 要望と要求の関係 参考資料まとめ 1. 要求工学 どのソフトウェア開発ライフサイクルモデルにも必ず存在するのが「要求定義/要件定義」というプロセスである。私にとって、いやおそらく多くのエンジニアにとって、これはプログラムを書くこと自体よりも非常に難しいプロセスである。 例えば顧客が「ごはんを食べたい」と言った時、私たちは何を明らかにし、何を考え、何
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
