要求は怪物みたいなもの
Angry Aussie / 青木靖 訳 2007年8月1日 水曜 8歳になる娘と話をすると、自分が何でもわかっているなどとは思わなくなる。 質問が上手なあの子は、私が答えられなかったり、少なくとも真剣に考えなきゃならないようなことを聞いてくる。真剣に考えるというのは重要で、いい加減な答えをしようものならすぐ突っ込まれてしまう。彼女が5歳で母親に日曜学校へ送り迎えしてもらっていた頃のある日、何の前触れもなくこんなことを聞いたことがあ った。 「ねえ、神様が私たちを作って、そして私たちを好きでいるなら、どうして神様は私たちが病気になるのをほうっておくの?」 あなたならどう答えるだろう? 私が最初に思いついたのは「ママに聞いてごらん」ということだった。しかしこれはその場しのぎにしかならない。最終的には「死なないくらいの病気かかると、かえって体が丈夫になるんだよ」という冴えない答でどうにか逃げお
「超上流」を成功させる17ヶ条：ITpro
日本情報システム・ユーザー協会（JUAS）が毎年実施している「企業IT動向調査」。その2006年版によれば，「500人月以上の大規模プロジェクトでは相変わらず5割近くで工期遅れが発生」，「大規模プロジェクトでは未だ4割近くで予算超過」，「大規模プロジェクトでは3割近くがシステムの出来上がりの品質に不満」と，企業情報システム開発では，納期，コスト，品質が予定通りに終わらない“失敗プロジェクト”がいまだに多い。 なぜ，企業情報システム開発では，失敗プロジェクトが多いのか。この点を，プロジェクトマネジメントを支援しているベテラン・コンサルタントや製造企業のCIO（最高情報責任者）と議論したことがある。その結論は，理由はいろいろあるが，プロジェクトマネジメントの観点で見れば「オーナーの弱さ」に尽きる，というものだった。 企業情報システム開発プロジェクトの「オーナー（持ち主）」は誰か。言うまでもなく
利害関係者の目的を可視化するプロセス
第1回（「視点を分けて業務システムを可視化」）は、この連載の入門編として、視点を分けて業務システムを可視化することの全体像について説明しました。また、モデルの具体的なイメージを持っていただくために、モデルを活用したRFP（モデルベースRFP）のサンプルを紹介しました。適宜、参照してください。
マインド・マップとUMLを使った要求分析支援（前編）：＠IT
マインド･マップをご存じでしょうか？ 最近、日本でも新しい「メモ技術」として注目されるようになってきた記法です。この記事では、このマインド・マップという記法が、ITの現場でうまく使えないだろうか、というアイデアを紹介します。特に、IT分野で標準化されているUMLをうまく補完するツールとして、要求分析という上流工程をまず取り上げたいと思います。 「顧客の言葉を集めること」の難しさ ITシステム開発において要求分析を行う場合、現在ではUMLを使ったオブジェクト指向による概念モデリングや、ユースケース分析が主流になってきています。しかし、UMLには強い制約（記法の意味と文法）があり、誰でもすらすらとまとまるものではありませんね。特に、顧客へのインタビューを行う場面では、その場でUMLにまとめるというのは至難です。そこで、顧客との対面場面ではとにかく「顧客の言葉を集める」ことに徹し、それをメモ（イ
System Requirements Specifications
システム要求仕様書の書き方 IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specificationより Table of Contents (目次) 1. Introduction (はじめに) SRSの「はじめに」では、SRS全体の概要を書く。 1.1. Purpose (目的) この小節では SRSの目的を描写する SRSが意図する聴衆を指定する 1.2. Scope (範囲) この小節では これから作るソフトウェア成果物に名前を付ける このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする 1.3. Def
要求管理と変更依頼管理の違いを理解しよう
どんなに注意深く要求を定義しても、ビジネス環境の変化や、顧客のシステムに対する理解の変化に応じて要求は変更されるものです。第5回「要求管理プロセスの流れを追跡する」では、要求の変更に対する管理プロセスの概要をお話ししました。今回は、特に要求への変更という観点だけでなく障害報告も含めた変更依頼という観点で、システムへの利害関係者の要望（Stakeholder Request）を管理する「変更依頼管理（Change Request Management）」を取り上げ、要求と変更依頼をきちんと分けて考えることによるメリットを解説します。 避けられない要求の変化にどう対処するか？ システム開発において、「初期の段階で要求を確定し、その後変更しない」ことが可能であれば、要求を実現するシステムを構築する開発チームにとっては、非常にうれしいことです。しかし、実際のシステム開発においては、初期の段階で要求
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
