鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
外部仕様書の構成について、確認してみる。 - ウィリアムのいたずらの開発日記
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 唐突ですが（理由は最後に書きます）、一度書いた気もするけど、 外部仕様書に必要な仕様書の構成について。 まあ、外部仕様書でなくても、プログラミング、あるいは詳細設計に入る手前に必要な仕様書とそのドキュメント構成とかんがえてもらっていいです。 で、その外部設計書の構成は、こんな感じだと思う。 ●表紙（なくても支障はないが） ●はじめに（ないときもある） ●目次（なくてもいいけど、ふつう、付けよう） ●修正記録（なくてもいいけど、付けろといわれることも） ●システム概要 →要求仕様で出てくる、大項目レベルの機能要件に関して、 体系的に文章でまとめる。これが、ちょー短い場合は、 はじめにに書いてしまって、ここはない。 ●ハードウェア構成 ●ソフトウェア構成・環境 本システムの位置づけ（
特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
マインド・マップとUMLを使った要求分析支援（前編）：＠IT
マインド･マップをご存じでしょうか？ 最近、日本でも新しい「メモ技術」として注目されるようになってきた記法です。この記事では、このマインド・マップという記法が、ITの現場でうまく使えないだろうか、というアイデアを紹介します。特に、IT分野で標準化されているUMLをうまく補完するツールとして、要求分析という上流工程をまず取り上げたいと思います。 「顧客の言葉を集めること」の難しさ ITシステム開発において要求分析を行う場合、現在ではUMLを使ったオブジェクト指向による概念モデリングや、ユースケース分析が主流になってきています。しかし、UMLには強い制約（記法の意味と文法）があり、誰でもすらすらとまとまるものではありませんね。特に、顧客へのインタビューを行う場面では、その場でUMLにまとめるというのは至難です。そこで、顧客との対面場面ではとにかく「顧客の言葉を集める」ことに徹し、それをメモ（イ
木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
上流工程-要件定義---目次：ITpro
NVIDIAの時価総額が526兆円で世界首位に、生成AIが促す11年ぶりの地殻変動 2024.06.19
非機能要件を見極める【前編】：ヒアリングでは不十分
「要件定義を難しくする」とクローズアップされてきたのが“非機能要件”の存在である。非機能要件とは，性能や信頼性，拡張性，セキュリティなど，機能要件以外のもの全般を指す。これらはユーザーへのヒアリングからだけでは洗い出しにくい。漏れがあると，稼働後のトラブルの種になる。こうした事態を未然に防ぐ，非機能要件の見極め方を探る。 旅行代理店のアールアンドシーツアーズは，今年10月末に予定しているホテル予約システムの稼働に向けて，今，開発の真っ最中だ。このシステムは，仕入れた航空券の在庫や宿泊の空室情報を管理するホストに，2次代理店からインターネット経由で送信されてくる予約データを受け渡すもの。 開発を主導する大平雅義システム部長は，「機能要件はほぼ固まったが，性能に関する非機能要件が懸案として残っていて悩ましい」と語る。 予約データはインターネットを介してやり取りされる。そこに含まれる顧客情報は暗
見積もりの肝―非機能要件：ITExpress
機能要件は、システムがユーザに提供する機能の観点から、「（ユーザやシステムとの）インタフェース」、「（業務）プロセス」、「データ項目」等を定義したものであるが、システム機能を実現するためには、もうひとつの要件である「非機能要件」も定義する必要がある。「非機能要件」は、システム機能を実現するための目標値として設定されるものであり、品質条件（運用性、信頼性、拡張性、性能、機能性、セキュリティ等）、技術要件（システム実現方法、開発方式、開発環境等）、運用操作要件、移行要件等に大別される。非機能要件の特性としては、より高いサービスレベル（例えば、より高い性能、より高い信頼性＜許容されるサービス時間短縮＞、より短い移行期間等）を実現するためには、より多くのコストがかかってしまうことが挙げられる。従って、本要件を定義する段階においては、お客様との間で、システムの特徴等を勘案してお客様の条件（コストも含
第6回 RFPの書き方：要件を確実に伝える表現のコツ
前回「RFPの書き方：どんなインターネットショップなのか？」では、「何を作りたいか」「何を目指すのか」など頭に思い描くシステムの完成イメージをRFPという形で文書にまとめて表現することの大切さや、およそどのようなことを書いたらよいのかという点について話を進めました。今回は、「どのように表現するか」ということについて、書き手の立場で注意すべき点について説明していきます。 どこまで詳細なRFPを作成すればよいか RFPを作成するのに当たり、まずはどこまで詳細に記述すべきかを明確にしておく必要があります。例えば、日曜大工仕事が得意なあなたの元に、友人から「本が増え過ぎたので机の横に置く本棚を1つ作ってくれないか。必要な費用は前もって払うから」という依頼があったとしましょう。当然、あなたはどのような本棚を望んでいるのか確認をすることでしょう。しかし、その友人は忙し過ぎて満足に説明する時間も取れず、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
