結城さんの「数学文章作法」を読んだ。この本自体が本の中で説明している作法を実践していて、素晴らしか...「数学文章作法」と「明文術」2010-11-21要求と、仕様と、ユースケースと。基本設計ここのところずっと要件定義をやっています。要件定義はUSDM/RDRA/ICONIXからエッセンスをもらって自分なりに組み合わせて使っています。そんなわけで、最近考えたことを少し整理してみる。なんか、以前にも書いたような気がしますが、現状の理...要求と、仕様と、ユースケースと。基本設計2001年出版の本ですが、最近こちらを読んでます。いう名称に変更しようと思います。IPOの「O」は「Output」のこと。Outputとは出力データである。システムはInputに対する処理(Process)の結果としてOutputを返す。Outputは処理の結果によって内容決まる。IPOの「P」はProcessのこと。Processとは処理のことである。システムはInputを受けて何かしらの処理(Process)を行い、Outputを返します。Output)について、頭の中でもやもやと考えていることを整理してみようと思います。IPOの「I」は「Input」のこと。Inputとは入力データである。Output)にもう少し拘ってみようかと。Output)を突き詰めてみたいと思っています。Output)にもう少し拘ってみようかと。仕様を分割して詳細化する際には分割手法のパターンを持っていると効率的です。これらはモジュール分割をする際の手法ですが、大きな仕様を詳細化する時に役立ちます。基本設計こちらもダウンロード可能になっています。基本設計IPAのサイトからダウンロード可能になっています。基本設計ユースケースを記述する際に、どの粒度で書くか?と悩む人は多いのではないでしょうか。各人の書きやすい粒度で良いと思うのですが、1つの指針を持って、その指針で書き切ることが重要だと思います。私自身もいろいろと試行錯誤してきましたが、最近1つの...ユースケースを記述する粒度2010-01-30抽象化とはプロセスである。するために、要求から仕様を導出する、各モデルによって分析、設計を行いますが、最初につまづく所がこの抽象化だと感じています。学ぶ、これまでの経験から練り上げられたプロセスによるテンプレー...抽象化とはプロセスである。Output)を紹介して頂きました。Output)を紹介して頂きました。id:good_wayさん、ありがとうございます。Output)を紹介して頂きました。Output)を時間が経ってから読み直してみると、自分で違和感を覚えました。UMLの図はどのように使われるか」には重要なエッセンスが詰まっています。そのエッセンスを噛み砕き、自分なりにまとめてみました。数年前に買っていた本で、久しぶりに読んでみると非常に重要なポイントがたくさん書かれていたので、ここで紹介します。今日はこれまでとは少し違う切り口です。ソフトウェアはプログラムによって作られます。プログラムはプログラミング言語を用いて開発します。プログラムはプログラミング言語がjavaであればクラスが連携して全体が構築されています。顧客が既に提供しているサービスがあり、そのサービスを実現しているシステムのリプレースを行う、というタイプの案件があります。顧客の要求を確実に仕様にできる要件定義マニュアルで説明される次のステップは「システムを把握する」です。要件を捉える4つのステップの最後のステップとなります。仕様(specification)と設計(design)。両者は文字通り異なるものです。当たり前のことなのですが、経験則としては普段明確に使い分けができていないことが多いのではないでしょうか。私なりに定義してみると以下のようになります。概念モデルをサンプルシステムを想定して作成してみました。整理が必要かもしれませんが、第一版としてはこのレベルとします。この後のユースケース記述では、この概念モデルを用語集として参照します。顧客の要求を確実に仕様にできる要件定義マニュアルで説明される次のステップは「システム境界を把握する」です。このステップでは大きく2つのことを把握します。それはユーザインタフェースとシステムインタフェースです。先のエントリーではさらっと「業務フローを書く」と書いたのですが、業務フローとユースケース記述(ユースケースシナリオ)って同じ様なことを書くよね?という疑問が出てきました。いう訳で、少し整理してみます。要求モデルを書く際に、要求とその理由から仕様を導出していきますが、悩んだり、手が止まってしまうことがあります。そんな時はアジャイルモデリングのプラクティスを参考にして「複数のモデルを並行して作ろう」と、次のステップに進み、また戻ってくれば...ステップ2:システムの外部環境を把握する2009-11-16ビジネスルールはアルゴリズムである。要件定義どこで読んだか忘れましたが、「ビジネスルールはユースケースではなく、アルゴリズムである」というものがあり、非常に納得した記憶があります。ビジネスルールは仕様としてそのアルゴリズムを明記し、ユースケース記述の中で参照することになります。ビジ...ビジネスルールはアルゴリズムである。中で最も難しいのはビジネスルール(お客様の業務における固有のルール)の仕様化ではないでしょうか。要求やその理由が明確になれば仕様を導出できます。その仕様化する上で、ビジネスルールを検証可能な仕様に落とし込めないと、後々に...要件定義の怪物、ビジネスルールをいかにして仕様化するか?2009-11-09何を顧客にヒアリングすべきか?要件定義コンテキストモデルを作成したら、要求モデルを作成するためにヒアリングをする、と以前に書きましたが、そこで疑問になるのが、「実際に何を顧客にヒアリングすべきか?」ということです。以前に紹介した組込みソフトウェア開発のための構造化モデリングでも説明に使われている話題沸騰ポットの要求仕様書が、SESSAMEのサイトにてサンプルとして公開されています。仕様が書けていますか?にて、<グループ>を使った要求の分割について説明されています。これは要求を分割する際に階層が深くなることを防ぐための手法となります。「明文術」はてなブログに移行しました。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。