要件定義

「数学文章作法」と「明文術」

結城さんの「数学文章作法」を読んだ。 数学文章作法 基礎編 (ちくま学芸文庫)作者: 結城浩出版社/メーカー: 筑摩書房発売日: 2013/04/11メディア: 文庫この商品を含むブログ (10件) を見る この本自体が本の中で説明している作法を実践していて、素晴らしか…

要求と、仕様と、ユースケースと。

ここのところずっと要件定義をやっています。要件定義はUSDM/RDRA/ICONIXからエッセンスをもらって自分なりに組み合わせて使っています。そんなわけで、最近考えたことを少し整理してみる。 要求とは? なんか、以前にも書いたような気がしますが、現状の理…

ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

2001年出版の本ですが、最近こちらを読んでます。ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)作者: アリスターコーバーン,Alistair Cockburn,ウルシステムズ株式会社,山岸耕二,矢崎博英,水谷雅宏,篠原明子出版社/メーカー: …

IRPSO 改め、IPO-RS

IRPSO(Input Reference Process Store Output) だと、IPO(Input Process Output) との関連が一見して分からないため、IPO-RS(Input Process Output with Reference/Store) という名称に変更しようと思います。

IPO(Input Process Output) / IRPSO(Input Reference Process Store Output)を再考する(「O」について)

次は「O」について。 Output IPOの「O」は「Output」のこと。Outputとは出力データである。システムはInputに対する処理(Process)の結果としてOutputを返す。Outputは処理の結果によって内容決まる。正常パターン、代替パターンに対するOutputを考える必要…

IPO(Input Process Output) / IRPSO(Input Reference Process Store Output)を再考する(「P」について)

次は「P」について。 Process IPOの「P」はProcessのこと。Processとは処理のことである。システムはInputを受けて何かしらの処理(Process)を行い、Outputを返します。なので、後は書くだけなのですが、InputやOutputだけだと処理を記述することが難しいた…

IPO(Input Process Output) / IRPSO(Input Reference Process Store Output)を再考する(「I」について)

IPO(Input Process Output) / IRPSO(Input Reference Process Store Output)について、頭の中でもやもやと考えていることを整理してみようと思います。まずは「I」について。 Input IPOの「I」は「Input」のこと。Inputとは入力データである。Inputとは、シ…

IPO(Input Process Output)にもう少し拘ってみようかと。

設計論ではなく、仕様化の手法として、IPO(Input Process Output)を突き詰めてみたいと思っています。

仕様の分割手法

仕様を分割して詳細化する際には分割手法のパターンを持っていると効率的です。 STS(源泉/変換/吸収)分割 TR(トランザクション)分割 共通機能分割 これらはモジュール分割をする際の手法ですが、大きな仕様を詳細化する時に役立ちます。

非機能要求グレード

こちらもダウンロード可能になっています。合わせて読みたい。NTTデータ

機能要件の合意形成ガイド

IPAのサイトからダウンロード可能になっています。要チェックですね。機能要件の合意形成ガイド

ユースケースを記述する粒度

ユースケースを記述する際に、どの粒度で書くか?と悩む人は多いのではないでしょうか。各人の書きやすい粒度で良いと思うのですが、1つの指針を持って、その指針で書き切ることが重要だと思います。 私自身もいろいろと試行錯誤してきましたが、最近1つの…

抽象化とはプロセスである。

要件定義、基本設計をするために、要求から仕様を導出する、各モデルによって分析、設計を行いますが、最初につまづく所がこの抽象化だと感じています。その原因は要件定義手法、設計手法を学ぶ、これまでの経験から練り上げられたプロセスによるテンプレー…

IPO(Input Process Output)の発展系IRPSO(Input Reference Process Store Output)を紹介して頂きました。

どうやって糸口を見つけるか? - 神崎コンサルノートにて、IRPSO(Input Reference Process Store Output)を紹介して頂きました。id:good_wayさん、ありがとうございます。 IPOを書く時に悩むこと IPO(Input Process Output)は考えた方は非常にシンプルで、書…

IPO(Input Process Output)の発展系IRPSO(Input Reference Process Store Output)で仕様化する

行き着く所はIPO(Input Process Output)を時間が経ってから読み直してみると、自分で違和感を覚えました。 Inputとなるものは、画面(入力)、イベント(要求/通知)、ファイルなど、そして引数を持たないメソッドもあるため、Inputがないこともあります…

開発プロセスとUMLモデル Quick Tour from UMLによるオブジェクト指向モデリングセルフレビューノート

UMLによるオブジェクト指向モデリングセルフレビューノートの「1-2 UMLの図はどのように使われるか」には重要なエッセンスが詰まっています。そのエッセンスを噛み砕き、自分なりにまとめてみました。 工程 要件定義 基本設計 機能設計/詳細設計 フェーズ …

UMLの参考書籍

数年前に買っていた本で、久しぶりに読んでみると非常に重要なポイントがたくさん書かれていたので、ここで紹介します。UMLによるオブジェクト指向モデリングセルフレビューノート作者: 荒井玲子出版社/メーカー: ディーアート発売日: 2005/04メディア: 単行…

行き着く所はIPO(Input Process Output)

今日はこれまでとは少し違う切り口です。ソフトウェアはプログラムによって作られます。プログラムはプログラミング言語を用いて開発します。プログラムはプログラミング言語がjavaであればクラスが連携して全体が構築されています。クラスはフィールド(デ…

サービス仕様という存在

顧客が既に提供しているサービスがあり、そのサービスを実現しているシステムのリプレースを行う、というタイプの案件があります。このような場合、RFPや顧客からの要求仕様だけを見ていると「なぜそのような要求があるのか?」という理由に当たる部分が分か…

ステップ4:システムを把握する

顧客の要求を確実に仕様にできる要件定義マニュアルで説明される次のステップは「システムを把握する」です。要件を捉える4つのステップの最後のステップとなります。このステップでは機能モデル、データモデル、そして必要な場合にはドメインモデルを把握…

仕様(specification)と設計(design)

仕様(specification)と設計(design)。両者は文字通り異なるものです。当たり前のことなのですが、経験則としては普段明確に使い分けができていないことが多いのではないでしょうか。私なりに定義してみると以下のようになります。 仕様(specification)…

概念モデルのサンプル

概念モデルをサンプルシステムを想定して作成してみました。もうちょっと整理が必要かもしれませんが、第一版としてはこのレベルとします。この後のユースケース記述では、この概念モデルを用語集として参照します。 ポイント クラス図で作成する。 クラス図…

ステップ3:システム境界を把握する

顧客の要求を確実に仕様にできる要件定義マニュアルで説明される次のステップは「システム境界を把握する」です。このステップでは大きく2つのことを把握します。それはユーザインタフェースとシステムインタフェースです。 ユーザインタフェース ユーザイ…

業務フロー V.S. ユースケース記述(ユースケースシナリオ)

先のエントリーではさらっと「業務フローを書く」と書いたのですが、業務フローとユースケース記述(ユースケースシナリオ)って同じ様なことを書くよね?という疑問が出てきました。という訳で、少し整理してみます。 業務フロー 業務フローはアクタをレー…

ステップ2:システムの外部環境を把握する

要求モデルを書く際に、要求とその理由から仕様を導出していきますが、悩んだり、手が止まってしまうことがあります。そんな時はアジャイルモデリングのプラクティスを参考にして「複数のモデルを並行して作ろう」と、次のステップに進み、また戻ってくれば…

ビジネスルールはアルゴリズムである。

どこで読んだか忘れましたが、「ビジネスルールはユースケースではなく、アルゴリズムである」というものがあり、非常に納得した記憶があります。ビジネスルールは仕様としてそのアルゴリズムを明記し、ユースケース記述の中で参照することになります。ビジ…

要件定義の怪物、ビジネスルールをいかにして仕様化するか?

要件定義の中で最も難しいのはビジネスルール(お客様の業務における固有のルール)の仕様化ではないでしょうか。要求やその理由が明確になれば仕様を導出できます。しかし、その仕様化する上で、ビジネスルールを検証可能な仕様に落とし込めないと、後々に…

何を顧客にヒアリングすべきか?

コンテキストモデルを作成したら、要求モデルを作成するためにヒアリングをする、と以前に書きましたが、そこで疑問になるのが、「実際に何を顧客にヒアリングすべきか?」ということです。突然、「今回のシステムついて要望を教えて下さい」と話しても、顧…

参考にすべき要求仕様書のサンプル(曖昧さを含んだものと曖昧さを排除したもの)

以前に紹介した組込みソフトウェア開発のための構造化モデリングでも説明に使われている話題沸騰ポットの要求仕様書が、SESSAMEのサイトにてサンプルとして公開されています。話題沸騰ポット 要求仕様書セミナの教材用の資料となっており、曖昧さを含んだ版…

続・要求を階層化して粒度を揃える分割手法(<グループ>分割)

先に紹介した要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?にて、<グループ>を使った要求の分割について説明されています。これは要求を分割する際に階層が深くなることを防ぐための手法となります。要求から仕様を導出するため…

RFP/要求仕様書/要件定義書の定義

(組織の)定義によって様々な呼び方が存在するRFP/要求仕様書/要件定義書ですが、ここでは以下のように整理して定義することとします。 RFP:顧客が作成する。システム開発に対する顧客の要求が記載されている。 要求仕様書:顧客が作成する。RFPとほぼ同…

要求を階層化して粒度を揃える分割手法

先に紹介した要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?にて、要求を階層化して粒度を揃えるための分割手法について説明されています。 時系列分割(時間軸分割) 構成分割 状態分割 共通分割 要求を仕様化する技術・表現する…

要求を仕様化する技術・表現する技術

要求モデルを作成する前に、勉強しておくべき書籍があるので紹介しておきます。著者は硬派なページの清水さんです。要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?作者: 清水吉男出版社/メーカー: 技術評論社発売日: 2005/10/07メ…

コンテキストモデルの再考。システム部担当者の存在。

コンテキストモデルから要求モデルを作成しようとしてみましたが、何か現実とは違う気がするので考え直してみました。足りないのはシステム部担当者ですね。システム部の担当者はシステム開発の企画、進行、保守に対して責任を持つ立場の人であり、システム…

要求モデルを作成する。

作成したコンテキストモデルを元にして、アクタ(役割)となる利用者にシステムに対するヒアリングを行い要求モデルを作成します。顧客の要求を確実に仕様にできる要件定義マニュアルでは要望/要求/要件を使い分けています。 要望:利用者(アクタ)からヒ…

コンテキストモデルを作成する。

システムの価値を明確化するための最初の手順として、コンテキストモデルを作成します。コンテキストモデルでは、システムを中心に配置し、システムを利用するアクタ(役割)とシステムと連携する外部システムを配置します。そしてノートにシステムの目的を…

ステップ1:システムの価値を明確化する

要件定義の最初のステップはシステムの価値を明確化することです。システムの価値を明確にするためには、その価値を享受する対象であるシステムを利用する人、システムと連携する外部システムを明確にする必要があります。その上でシステムが果たすべき役割…

サンプルシステムの概要

題材にするサンプルシステムの概要は以下の通りです。 サンプルシステムはA社向け統合EMS(Element Management System)。 A社では無線機などのネットワーク装置を用いて自営網を構築しているが、これまでは各装置のメーカであるX社、Y社、Z社のそれぞれのEM…

要件を捉える4つのステップ

顧客の要求を確実に仕様にできる要件定義マニュアルでは要件を捉えるための4つのステップについて紹介しています。 システムの価値を明確化する。 システムの外部環境を把握する。 システム境界を把握する。 システムを把握する。 顧客の要求を確実に仕様に…

アプリケーションのセキュリティ要件をどのように扱うか?

RFPのシステム要件にある「アプリケーションのセキュリティ要件」を、機能要件とするのか?非機能要件とするのか?は難しい問題です。現状の私の考えは以下の通りです。 認証と識別(ログインとユーザ管理)、ユーザ操作履歴の記録など、ユースケースとして…

要件定義とは?

要件定義とは、一言で表現すると「開発するシステムの設計を行う上での前提条件となる要件を定義する」ことです。具体的には4つの要件 - ken’s room 〜技術探求のメモ〜にて説明したRFPに記載された4つの要件から、機能要件と非機能要件を定義します。RFP…

設計手法の参考書籍

要件定義や基本設計において、ドメインモデリング(概念モデリング)、ユースケースモデリングを行いますが、そのために必要なモデリングの手法について参考になる本を紹介します。 洋書(の翻訳)はあまり好きではないのですが、ダグ・ローゼンバーグとスコ…

絶対に抜かしては行けない、開発側のスタート地点

要件定義はシステム開発のプロジェクト側が、お客様のRFPを元に、開発するシステムの要件を仕様として定義する工程です。昨今の傾向として、短納期・低予算という厳しいプロジェクトが多く、その結果としてこの要件定義工程が削られます。そのような場合、箇…