要件定義

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

結城さんの「数学文章作法」を読んだ。 数学文章作法 基礎編 (ちくま学芸文庫)作者: 結城浩出版社/メーカー: 筑摩書房発売日: 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のサイトにてサンプルとして公開されています。話題沸騰ポット 要求仕様書セミナの教材用の資料となっており、曖昧さを含んだ版…

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

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