業務フロー V.S. ユースケース記述（ユースケースシナリオ） - Ken's Blog
先のエントリーではさらっと「業務フローを書く」と書いたのですが、業務フローとユースケース記述（ユースケースシナリオ）って同じ様なことを書くよね？という疑問が出てきました。という訳で、少し整理してみます。 業務フロー 業務フローはアクタをレーンに配置し、ユーザの業務をフローとして記述しながら、業務の流れとシステムとの接点を明確にするものです。つまり、焦点は文字通り業務の流れにあります。 ユースケース記述（ユースケースシナリオ） ユースケース記述（ユースケースシナリオ）はユーザとシステムの対話をシナリオとして記述するものです。つまり、焦点はユーザとシステムの対話にあります。 個人的な見解 業務が複数のアクタによって複雑に絡み合う様な場合は業務フローを書くことで整理することができます。しかし、通常はそこまで複雑な業務は少なく、どちらかと言えば、システム化する上でユーザとシステムがどのような対話を
IPO(Input Process Output)の発展系IRPSO(Input Reference Process Store Output)で仕様化する - Ken's Blog
行き着く所はIPO（Input Process Output）を時間が経ってから読み直してみると、自分で違和感を覚えました。 Inputとなるものは、画面（入力）、イベント（要求／通知）、ファイルなど、そして引数を持たないメソッドもあるため、Inputがないこともあります。 また、Processが状態を持つ場合、その状態もInputになり得ます。 Processが状態を持つ場合に、その状態もInputになり得る、と書いたものの、これは参照（Reference）しているのであって、Inputとは少し違わない？ Outputとなるものは、画面（出力）、イベント（応答／通知）、ファイルなど、そして戻り値を持たないメソッドもあるため、Outputがないこともあります。 また、メソッドを呼び出した側には何も返さないが、DBに保存する、ファイルを生成する、通信をする、などもOutputになり得ます。
要件定義とは？ - Ken's Blog
要件定義とは、一言で表現すると「開発するシステムの設計を行う上での前提条件となる要件を定義する」ことです。具体的には４つの要件 - ken’s room 〜技術探求のメモ〜にて説明したRFPに記載された４つの要件から、機能要件と非機能要件を定義します。 RFPの４つの要件と要件定義の機能要件、非機能要件との対応は以下になります。 RFPの業務要件（＋システム要件の一部）＝機能要件 RFPのシステム要件＋運用要件＝非機能要件 （RFPのプロジェクト要件＝プロジェクト計画書） つまり、RFPの業務要件から機能要件としてシステムに必要な機能とデータを定義し、RFPのシステム要件／運用要件からシステムに求められる前提条件を非機能要件として定義します。 ここで繰り返しになりますが、上記のようにRFPの４つの要件と要件定義の機能要件、非機能要件を対応付けていますが、経験則から言って、RFPの要件が明確
４つの要件 - Ken's Blog
RFP作成 実践!ガイドでは、RFPの記載内容として４つの要件について説明している。４つの要件とは以下の通り。 業務要件 システム要件 プロジェクト要件 運用要件 業務要件 業務要件として記述する一般的な記載例は以下の通り。 1. 業務要件のベースにある考え方 1.1 背景 1.2 目的 1.3 期待効果 2. 業務概要 3. 新システム概要図 4. 業務記述書 5. 業務フロー 6. 業務一覧 7. 入力一覧 8. 出力一覧 9. コード定義 10. データ定義 11. インタフェース定義 12. 旧システムからの移行要件 13. 新システムの研修 14. 特記事項 RFP作成 実践!ガイド システム要件 システム要件として記述する一般的な記載例は以下の通り。 1. システム概要図 2. システム環境 2.1 ネットワーク環境 2.2 ユーザ環境 3. 処理方式 4. 他システムとのイン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
