ソフトウェア顧客の要求に関する権利宣言と責任宣言 - 勘と経験と読経
いつか読もうと思っていた名著「ソフトウェア要求 第3版」を読んでゐる（例によってKindleのセールで購入。なお現在はほぼ定価に戻ってるので注意） 以前にこのブログで言及したソフトウェア顧客の権利と義務についての章を読んだのでその雑感と関連思考について。オチはない。 「ソフトウェア要求第3版」では 以前に記事で引用したソフトウェア顧客の要求に関する権利宣言と責任宣言を、改めて原点の「ソフトウェア要求第3版」で確認した。第2版とおそらく変化していないと思うのだけれども確認はしていない。 ソフトウェア顧客の要求に関する権利宣言 ビジネスアナリストが、あなたが使用することばを話す ビジネスアナリストが、あなたのビジネスと目標について学ぶ ビジネスアナリストが、適切な形式で要求を記録する 要求プラクティスと成果物に関する説明を受ける 要求を変更する 互いを尊重する環境を期待する 要求とソリューショ
【書評】はじめよう！要件定義 -ビギナーからベテランまで - GoTheDistance
著者の羽生章洋さんより献本御礼。 はじめよう! 要件定義 ~ビギナーからベテランまで 作者: 羽生章洋出版社/メーカー: 技術評論社発売日: 2015/02/28メディア: 単行本（ソフトカバー）この商品を含むブログを見る 本書の特徴を一言で言うなら、「これ以上に必要なことはないが、足りていないことは何もない」という絶妙なバランス感です。サラッと読める分量にしているのに、各章を良く読み込んでいくと気付かされることが多く、豊かな行間があります。 要件定義というテーマはとても扱いが難しくバランスをとるのが難しいのに、本書は170p弱でまとめあげている。しかも、イラストも結構多い。この分量で大丈夫なのかと勝手に思ったが、最後のほうではDB設計の話も出てくる。データ設計も要件定義の範囲として捉えているのも、実装を重んじる羽生さんらしいアプローチだし、そこまで考えないと要件として不十分だよねっていう
（第2回）ダメ発注その1、要件定義もできない“低クオリティ”
ユーザー企業には「発注責任」がある。しかし実際には、この当たり前のことをわかっていないユーザー企業は数多い。その結果、システム開発プロジェクトが頓挫し、ユーザー企業とITベンダーの双方が大きな打撃を受けるケースが頻発している。この特集では、ユーザー企業がシステム開発をITベンダーに発注する際に陥りがちな問題点を、発注のQCD（品質、料金、期日）の観点から分析する。 今回は“Q”、つまり発注の品質にフォーカスして問題点をあぶり出す。なお、この特集は日経コンピュータの2008年6月15日号に掲載した記事をベースに、内容を一部修正して著者の現時点での認識などを加えたものだ。オリジナルは4年半前の記事だが、ITベンダーの事業部長、営業部長クラスの人に匿名を条件に語ってもらった“事実”は、今でも全く古さを感じさせない。 一括契約はここが恐ろしい 発注の品質、つまり要件定義の問題は、ほぼすべてのITベ
僕の要件定義アプローチを整理してみる - Life is Really Short, Have Your Life!!
あとでメインのブログにまとめようと思うので、軽めに書いておきます。 先日要件定義の手伝いを頼まれたことも踏まえて、少し自分の考えをまとめたいと思います。 コンピュータに出来ることは少ない 最初に訪れる問題は、システムで行えること・達成できることを大風呂敷を広げた状態で考えていないかどうかの確認です。Amazonと同等のレコメンドエンジンが欲しい！って言われても、はいそうですかと出来る話ではございません。 打ち合わせをしていくと「コンピュータに任せればあとはよしなにしてくれる」という空気感は、必ず所々に出てきます。そこを詰めていかないと認識がずれたままなので、いかにコンピュータでやることを具体化出来るかというのが要件定義の最重要課題だと思います。 業務フローを書こう 細かいのは要らん。決めたいのはシステムを利用する仕事の世界地図。見積から受注までの管理が必要なのか、売上のBIを分析したいのか
リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク - プログラマの思索
リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンクをメモ。 【参考】 「要件定義」の4つの構造と依存関係に着目した実践手法 （1/5）：CodeZine 要件定義工程の進め方 （1/4）：CodeZine 構造に沿って要件をUMLで具体的に定義する （1/3）：CodeZine 要件の精度を向上させる （1/3）：CodeZine レビューを軸に駆動する （1/4）：CodeZine 既存システムを分析するコツは「システムの地図」を作ること （1/3）：CodeZine 既存システムを分析するための考え方と対処法 （1/5）：CodeZine UMLを使った既存システムの分析 （1/3）：CodeZine 要件定義ツールを使った既存システムの分析 （1/4）：CodeZine プログラムをマクロ（大域的）に分析する （1/3）：CodeZine RDRA リレーションシ
欲望を要件定義しないと何も手に入らない - インターネットの備忘録
離婚してからこっち、自己評価が最底辺付近をずっと彷徨ってたんですよね。 どんな職場でも、どんな異性でも、どんな同性でもいいから、わたしを受け入れてくれる相手なら、なんでもいい。くらいの感じだったんですけれども、最近目が覚めまして、覚めたっていうか、好いてくれてるならいいかっていう程度の相手とクソみたいな時間を過ごしてしまって、死ぬほど後悔して自覚したというか、こんなんじゃダメだと思ったんですよね。 そんで他方で、最近オシャレ女子たちとの交流が増えてきたんですが、まー彼女たちのお洋服選びにかける情熱？執念？の凄みが、ある種感動的でですね。例えば、「この秋に新しいボトムスが欲しいな〜」と思うとしますよね、わたしのようなあんまりお洋服にこだわりのない人間だと「秋だし、ちょっと大人っぽいめで、なんとなく膝丈くらいで、手持ちの服に合わせやすければよくて、タイトスカートでもいいけど別にフレアでもまあい
「必要なこと」より「excelでやりたいこと」を優先するとシステム構築は失敗する - プロマネブログ
<追記> 追加記事を書きましたhttp://getlife.hateblo.jp/entry/2013/12/07/034949 エクセルでできることができない何百万のシステム・・ 多分現場の人かな。往々にして、システム導入を決定したトップの目的が現場に伝わらず、既存ツールとの差だけが目につくってことはよくあるし。ま、一部業務をexcelで残すみたいに調整すればいいんじゃないかな。 オッサン、こういうシステムネタ好きです。昔高度情報技術者試験を受けた時を思い出すなあ。 大体、仕事やっているとこの手の「今やっている仕事と違う～」だとか、「役員はシステム導入ばっかり言って現場をわかってない」とかそんな揉め事ばかり。 まあ、そういう揉め事を丸め込む納得できるよう調整するのがオッサンの仕事なんですけどね。 本当にやりたいことを見つける システムの要件定義のキモは 必要なこと やりたいこと やらない
OSSにない機能要求が続出、第三者の視点でアドオン抑える
利便性向上、利用分析および広告配信等のためにクッキーを利用してアクセスデータを取得しています。詳しくは「データ利用について」をご覧ください。オプトアウトもこちらから可能です。
スーツとギークという区分けがなくなった時代の理由 - 山本大＠クロノスの日記
id:gothedistanceのエントリで話題になってた1つのコメントが、まさに僕のブログに対してつけられたコメントでした。 http://d.hatena.ne.jp/iad_otomamay/20100216/1266333904#c1273690204 上記の「コメント主」に対して言いたいことはなにもないのですが、 id:gothedistanceの話題に少し触発されて、僕がリーマンショック以後の日本のSIerにいて感じることを述べます。 テーマは「スーツとギークという区分けがなくなった時代の理由」です。 （とりあえず、皆がスーツとかギークとかいう論争に飽きたことという理由は除いて語ります。） もはや、今の時代のSI業界では「要件定義だけやるからあとヨロシク」と言って逃げられる人はいなくなりました。 理由のひとつは、簡単な話です。 理由 1. 不景気で逃げる先の仕事がなくなった さ
机に向かって取れる解決法だけを並べて「限界だ」なんてあきらめてないか？ - レベルエンター山本大のブログ
プロジェクトで発生する様々な問題の答えは、IT技術や開発の方法論だけではありません。 問題解決のためには、あらゆる手段を視野に入れてのぞむ必要がありますが、 僕らエンジニアは「あらゆる手段」を狭く取りすぎていることがあります。 「あらゆる」と言いながら、机の前、パソコンの前に座って取れる方法だけにとらわれていたことが 僕自身にもありました。 そのプロジェクトのエンドユーザーさんはとても田舎の工場で、 僕が勤務してた大阪の市内からは、車で行って2時間（高速代などで10000円）、 電車で行くと2時間40分（片道3000円）かかるところにある、 なかなか厳しい立地条件のお客さんでした。 僕はこの案件で、要件定義から参画しましたが、 ミーティングをするために、客先に出向いても往復に4時間以上かかるので せいぜい3時間しかミーティングの時間が取れません。 このため時間的にもお金的にも、ミーティング
上流工程に積極的に参加を 当事者意識が欠けてはいないか
上流工程に積極的に参加を 当事者意識が欠けてはいないか 西村 規子氏 サイバーエージェント 経営本部 財務経理室 シニアマネージャー 「顧客の指示どおりにシステムを構築すれば良い」。こう考えているITベンダーが多いように感じる。間違ってはいないが、顧客が要件定義を円滑に進めるための支援に、もっと力を入れてほしい。 当社は主力のインターネット広告ビジネスを強化するため、ブログサービス「Ameba」の運営などさまざまな事業を立ち上げた。これに伴いシステム化の範囲も広げている。 導入ノウハウのないシステムを構築する場合、どこまでシステム化すべきか、どの技術を適用すべきかなどの作業で苦労しがちだ。ITベンダーには要件定義など上流工程から、要件がぶれないよう、気付きを与えてもらえると助かる。 例えば、利用部門の機能追加の要求について、「システム化するよりも人手による運用で対応すべき」と感じたら、指摘
Í×·ïÄêµÁ¡¦´ðËÜÀß·× - µ»½Ñ¾ðÊóWiki
´ðËÜÀß·× † ¥·¥¹¥Æ¥à¤Î¥ê¥×¥ì¡¼¥¹°Æ·ï¤¬ºÇ¤â´í¸±¤ÊÍýͳ 2008.2.24 ±¿ÍѤ·¤Æ¤¤¤¯¤¦¤Á¤Ë¡¢¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤äµ¡Ç½Äɲäǡ¢¶²Îµ¤Î¤è¤¦¤ËÇϼ¯¤Ç¤«¤¯¤Ê¤Ã¤¿Ãæ¿È¤Ï¡¢ºÇ¿·¤Î¥ª¥Ö¥¸¥§¥¯¥È»Ø¸þ¸À¸ì¤Ç¡¢Æ±¤¸¤è¤¦¤Ë¤¿¤¯¤µ¤ó¤Î¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤ò½Å¤Í¤ÆÀѤ߾夲¤¿¤â¤Î¤ËÊѤï¤ë¡£ Ʊ¤¸¥½¡¼¥¹¥³¡¼¥É¤ÎÃÇÊҤϰì¤Ä¤â¤Ê¤¤¤Ï¤º¡£ ¥×¥í¥°¥é¥à¤ÎÊݼéÀ¤ä°Ü¿¢À¡¢ºÆÍøÍÑÀ¤¬¡¢¤É¤Î»þÂå¤Ë¤Ê¤Ã¤Æ¤â¡¢¸À¸ì¤¬¤¤¤¯¤éȯŸ¤·¤Æ¤âÆñ¤·¤¤¤³¤È¡£ Æä˺ÆÍøÍÑÀ¤Ï¡¢¤½¤Î¥
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
