[B! requirement] bobbyjam99のブックマーク

[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita

下記ドキュメントバージョンに関する注意点です。バージョン番号のルールを定める：バージョン番号は、どのようにつけるかルールを定め、チーム全員が同じ理解で使用するようにする必要があります。たとえば、変更内容によって数字がどのように増えるか（major, minor, patch）、何桁で表現するかなど、具体的に決めておくことが重要です。変更履歴を明確にする：どのような変更があったのか、それがどのバージョンで実施されたのかを明確にすることが必要です。これにより、何らかの問題が発生した場合に、どのバージョンから問題があるのか特定することができます。ドキュメントの保存場所を一元化する：ドキュメントのバージョン管理には、ドキュメントを保存する場所を一元化することが重要です。それにより、異なるバージョンのドキュメントが、複数の場所に分散してしまい、誤ったバージョンが使用されることを防ぐことができま

bobbyjam99 2022/10/10

requirement

リンク

Agile and Requirement : アジャイルな要件定義について考える

アジャイルマニフェストとユーザーストーリーマッピングのお話です。

bobbyjam99 2022/05/24

リンク

技術情報 / 要求開発超入門 | リコーソフトウエア株式会社

リコーソフトウェアが今全社一丸となって取り組んでいる要求開発とは何か本連載では、要求開発を深く理解してもらうために、誰にでもわかる要求開発を目指して、分かりやすい説明をしていこうと思う。

bobbyjam99 2009/02/16

リンク

第3回　システム要求の探究（その3）＝要求の開発とは

ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第1回と第2回では、「要求とは何か」について旅をしてきました。第3回は、要求の開発という世界を探求していきます。ここまでみなさん、楽しい旅ができていますか？この旅が、もっと楽しくなるように、さらに常識を崩していきましょう。創発号の出発です。次に挙げるのは、業務改善・業務改革ソリューションで失敗しないために、一般的に言われている常識です。ですが、大切なことは、これらをまずは疑ってみることです。要求に伴う、疑うべき四つの常識 ●常識１：要求はユーザーから聞き出すもの今回までの“創発号”の旅の中ですでに、このことが「おかしいのかも」ということには気が付いたと思います。ユーザーの業務を知り、ユーザーがやりたいことを聞きだすことは、基本としては正しいでしょう。しかし、それだけではダメなのです。ITの使い方は、ITの

bobbyjam99 2009/02/16

常識を疑え．

リンク

要求は怪物みたいなもの

Angry Aussie / 青木靖訳 2007年8月1日水曜 8歳になる娘と話をすると、自分が何でもわかっているなどとは思わなくなる。質問が上手なあの子は、私が答えられなかったり、少なくとも真剣に考えなきゃならないようなことを聞いてくる。真剣に考えるというのは重要で、いい加減な答えをしようものならすぐ突っ込まれてしまう。彼女が5歳で母親に日曜学校へ送り迎えしてもらっていた頃のある日、何の前触れもなくこんなことを聞いたことがあった。「ねえ、神様が私たちを作って、そして私たちを好きでいるなら、どうして神様は私たちが病気になるのをほうっておくの?」あなたならどう答えるだろう? 私が最初に思いついたのは「ママに聞いてごらん」ということだった。しかしこれはその場しのぎにしかならない。最終的には「死なないくらいの病気かかると、かえって体が丈夫になるんだよ」という冴えない答でどうにか逃げお

bobbyjam99 2008/10/20

"要求も何層にもなっていて、中心にたどり着くまで一枚一枚剥いでいく必要がある。そうやってプログラマにどう伝えればいいのかがわかるんだ"

リンク

http://www.hakkaku.net/rdd/index.html

bobbyjam99 2007/11/02

リンク

■ - レベルエンター山本大のブログ

現在、プロジェクトの基本設計フェイズに入っていますが、後続で入ったので要件の全体像把握に手間取りました。そういったことから基本設計フェイズでは、「要求リスト」を活用するのが良いと感じています。要求リストは以下のような項目として作ります。 No 分類要件優先度難易度備考 ※分類項目には、「機能要件」 Or 「UI操作性要件」を記入する。現場で活用する場合、基本設計書の第1章として要求リストを記載しておいて常にヒアリングセッションの傍らに置いて話を進めるという使い方をします。このリストのメリットは・要件に対する関係者の合意がとれ、常に認識が一致する。・仕様の漏れを減少することができる。・後続参加メンバーや、同プロジェクトの別チームへの設計意図の伝達に利用できる。・見積に利用できる。などなどです。メリットの中でも「仕様漏れの減少」は有意義です。仕様漏れが発生

bobbyjam99 2007/08/27

要求リスト例．『No, 分類, 要件, 優先度, 難易度, 備考』

リンク

橋本正徳の「あなたのためのシステム開発」 : 「要件定義」について - livedoor Blog（ブログ）

「要件定義」については、「顧客からヒアリングなどを行いシステムの仕様を決定する作業」だとか、「ビジネスやシステムの課題を明らかにし、あるべき姿（要求仕様）を列挙すること定義します。」だとかって書かれていたりします。・システム化のための要求定義の品質向上・「見える化」でソフトウェア開発！まぁ、そんなニュアンスのものです。「要件定義」という作業は、とても大事で、じっくり検討しなければならないところだと思います。この「要件定義」の仕上がり次第で、実際の開発のときのコストとスピードが大きく変わるので、さらに重要度は高くなります。また、システム開発の担当としても、お客様との初めての共同作業の場です。とても大事に思います。インターネットに公開するタイプの、いわゆる「Webコンテンツ」は、「Web制作会社」というデザイナ寄りの会社、もしくは、うちのような、プログラマ寄りの

bobbyjam99 2007/08/09

パワポのシンプルさをまねしたい

リンク

マゴの手要件定義

要件定義を行う最中には，ちょっとした問題でマゴマゴしてしまうことが往々にしてあります。なかなか解説書の通りにはいかないものです。今回は，そんな“マゴマゴ”に手が届く，要件定義の「マゴの手」をご紹介します。なお，ここでは，要求をヒアリングする対象の人を「ユーザー」としています。ユーザー企業の情報システム部門にとっては，「ユーザー部門」の人であり，SIerにとっては「顧客」に相当します。 ■よくあるマゴマゴ「ユーザーからスケジュール通りに仕様が出てこない！」よくありますよね。早く決めて，次の作業へ進みたいのに，なかなか出してもらえない。でも「早く出してください！」の一点張りではらちが明きません。そんなときは，このマゴの手で行きましょう。解決！マゴの手：【こちらから出す】例えば，外部委託で開発を行う場合，開発を請け負った側は，必ずしもユーザーから仕様が出てくるまでひたすら待つことはあ

bobbyjam99 2007/07/26

リンク

ユーザーと共通理解できる“システム観”が必要だ－＠IT情報マネジメント

企業システム開発では、しばしばユーザーの思いどおりのシステムに仕上がらないことがある。その大きな原因の1つが、ユーザーの“要求”と開発者の“理解”のズレだ。ユーザーと開発者が共通認識にたどり着くには、何が必要だろうか？（→記事要約<Page2>へ）業務システム向けの分析設計技法としてさまざまなやり方が提唱されています。有名なところがUMLを用いた「オブジェクト指向分析・設計手法」です。しかし、開発現場で実際に利用されているのは、昔から無批判に繰り返されてきた古めかしいやり方だったり、せいぜい「UMLもどき」とでもいえそうな案件ごと独自に「工夫」されたやり方です。 UMLは、バラバラだったオブジェクト指向系の表記法を統一するための体系として鳴り物入りで登場しましたが、必ずしも当初の期待どおりの効果を挙げているわけではありません。それは、システム開発においてボトルネックになっているのが「シス

bobbyjam99 2006/05/09

分析設計技法「三要素分析法」集中講座（1）

リンク

はてなブックマーク

タグ

関連タグで絞り込む (7)

requirementに関するbobbyjam99のブックマーク (10)

お知らせ

今週のはてなブックマーク数ランキング（2025年2月第4週）

今週のはてなブックマーク数ランキング（2025年2月第3週）

今週のはてなブックマーク数ランキング（2025年2月第2週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!