システム構築の上流工程強化（非機能要求グレード）：IPA 独立行政法人 情報処理推進機構
国民生活や社会経済活動における基盤となった情報システムは、「大規模化・複雑化」、「利用の広がり」の点からますます高度化しています。このような高度化に伴い、情報システムの安定的なサービスが求められるようになっており、複雑なシステムを構成する多様なコンポーネントがきちんと連携してそのようなサービスを提供する「システム基盤」の実現が重要になっています。そのためには、提供したいサービスに対応する要求を適切に定義する必要があります。 「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。重要な項目から順に要求レベルを設定しながら、両者で非機能要求の確認を行うことができるツール群です。 【非機能要求グレード2018】
株式会社マジカジャパンの羽生章洋が書いてるブログ:業務フローと構造化技法とマジカ！ - livedoor Blog（ブログ）
先日、ITマジカ！をリリースしました。おかげさまで滑り出しは好調です。本当にありがとうございます。さて、ITマジカ！をリリースしたことで、今まで何年間も講演などで業務フローと業務システムの関係についてお伝えしてきたことが絵面として表現できるようになったので、少し触れてみます。 現場の人にとっての関心事は「業務が回るかどうか」ということです。一方でIT化を請け負う開発者サイドは「何を作れば良いか」が関心事になります。さてここで、業務が回るというのは要するに個々人のアクティビティが滞りなく完了するということです。一段上のレイヤーにおいては業務フロー即ち全体の仕事の流れが流れることが大切なのですが、そのレイヤーに対して日常的に責任を持つ人はいないので、個別のタスクが止まらないかどうかが表面上の気になることとなります。 この個別のタスクというのは、上記の図では緑のところに該当してマジカ！で書き出し
業務フロー V.S. ユースケース記述（ユースケースシナリオ） - Ken's Blog
先のエントリーではさらっと「業務フローを書く」と書いたのですが、業務フローとユースケース記述（ユースケースシナリオ）って同じ様なことを書くよね？という疑問が出てきました。という訳で、少し整理してみます。 業務フロー 業務フローはアクタをレーンに配置し、ユーザの業務をフローとして記述しながら、業務の流れとシステムとの接点を明確にするものです。つまり、焦点は文字通り業務の流れにあります。 ユースケース記述（ユースケースシナリオ） ユースケース記述（ユースケースシナリオ）はユーザとシステムの対話をシナリオとして記述するものです。つまり、焦点はユーザとシステムの対話にあります。 個人的な見解 業務が複数のアクタによって複雑に絡み合う様な場合は業務フローを書くことで整理することができます。しかし、通常はそこまで複雑な業務は少なく、どちらかと言えば、システム化する上でユーザとシステムがどのような対話を
要件定義とは？ - 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. 他システムとのイン
DSMとは｜用語集｜株式会社ITID
業務の流れをマトリクス形式に整理し、手戻りなどの問題を可視化・分析する手法のこと。または、その手法を用いて作成された表を指す。 DSMを作成するためには、まず、業務を構成するタスクを列挙し、それらを表の行方向と列方向に同じ順序で並べる。次に、それらタスク間の依存関係を"総当り表"として記入する。 ここで、「タスク間に依存関係がある」とは、一方のタスクから出力される情報が他方のタスクの入力として使われている状態を表す。 このように情報の入出力の流れに着目してタスク間の依存関係をDSMに整理することで、製品開発プロセスのように把握しづらい仕事の流れが可視化され、業務の中で発生している手戻りなどの問題点を分析することが可能となる。これを「タスクDSM」と呼んでいる。 なお、DSMの分析対象は業務プロセスにとどまらない。たとえば製品アーキテクチャをDSMにより可視化することで、モジュール化に向けた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
