ホーム

ブログ

[要件のツボ]バージョン1.5公開

2012-02-02(木) 11:07 — kanzaki

先週「要件のツボ」バージョン1.5を先週公開した。

このバージョンではパッケージの関係をグラフィカルに表示し、その関係を調整できる「パッケージ登録」を追加した。

当面の積み残し機能の中で最後に残っていた重要な機能である。

ある程度規模の大きなシステムになると、サブシステム分割が欠かせない。

そこで「要件のツボ」ではサブシステムに対応するものとしてパッケージを対応させ、同じくUMLのパッケージにも対応させた。

パッケージに分割すると今度はパッケージ間の関係が重要になる。

そこでパッケージ登録画面では、パッケージ間の関係をグラフィカルに表示し、各々の関係の詳細を表示出来るようにした。

定義情報をパッケージ間で移動させることで関係を調整できる機能も用意した。

＜早わかりビデオ集＞要件定義支援ツール【要件のツボ】

これで規模の大きな要件定義にも対応出来るようになった。

サブシステム間の依存関係を一目で見られる機能は既存システムの分析で一番効果を発揮すると考えている。

画面、イベントとデータをパッケージに分割し、それらの関係を整理することでシステムの全体像が見えてくる。

画面、イベントとデータは機能でつなぎ、機能とデータはCRUD分析で結びつける。

＜早わかりビデオ集＞要件定義支援ツール【要件のツボ】

業務の流れは状態とその遷移で表現し、その遷移に画面とイベントを紐付ける。

[要件定義]要件定義と要件のツボ

2012-01-04(水) 13:56 — kanzaki

１０年ほど前より要件定義をUMLで行い、徐々にUMLでの要件定義が体系化してきた。

そして、2008年にAmazon.co.jp： 顧客の要求を確実に仕様にできる要件定義マニュアル: 神崎 善司: 本の執筆を機会に要件定義の手法としてまとめ上げることができた。

出版をきっかけに、具体的に案件で利用しているかた方からフィードバックをいただき、応用範囲が広がっている。

この体系化をもとに一昨年は既存システムの分析を実践し、昨年何回かその成果をプログラムの大海に溺れないために発表した。

やはり既存システムの分析は苦労している方が多く、実際に「既存システムの分析のサービスはないかと」何回か打診を受けた。

しかし、既存システムの分析を素手で行うのは無謀。

スライドにもまとめたがトップダウンとボトムアップのアプローチを併用して短期間にまとめ上げる目処をつけたので、この機械化も今後のテーマである。

一方要件定義の方はUMLを使わない「要件のツボ」に注力し、はじめて要件定義を行う人でも短時間に要件をまとめられるツールにまとまってきた。

次のバージョンでは細かな改善と同時にパッケージ間の関連をグラフィカルに表示し、その関連をドラッグ＆ドロップで調整する機能を追加した。

これで規模の大きいシステムの要件定義をサブシステム分割して定義できるようになり、同時に関係性の調整もできるようになった。

このバージョンは今月中には公開する予定である。

昨年要件定義の勉強会を何度か開き、その中でUMLツールか要件のツボのどちらかを選択できるようにした。結果的には多くの人が要件のツボを選択して要件定義を行い、短時間で要件を洗い出すことができた。

[SCALA]F#とScala　F#勉強会メモ

2011-10-08(土) 11:53 — kanzaki

昨日のF#勉強会の演習をScalaで組み直しコードを比べてみた。

F#のPartition関数をたたみ込み関数を使って作成する

自分のいつもの癖で関数型で考えるときはパターンマッチで再帰を使って考える癖がある。

そもそもこの時点で演習課題とずれているのだが、foldでいきなり考えられないのでまずはパターンマッチで考えた。

昨日は時間切れで完成せず家に帰って、中村さんの答えを参考に復習した。

F#バージョン

let partition (f:'a -> bool) (lst:'a list):('a list * 'a list) =
    let comp (list1,list2) v = 
        if(f v) then (v ::list1,list2) else (list1,v :: list2) 
    List.fold comp ([],[]) lst

これをScalaで書き直してみた

Scalaバージョン

def partition1[T](f:T=>Boolean,lst:List[T]):Pair[List[T],List[T]] = {
    def comp(tpl:Pair[List[T],List[T]],v:T):Pair[List[T],List[T]] ={
       if(f(v)) Pair(v :: tpl._1,tpl._2) else Pair(tpl._1,v :: tpl._2)
    }
    lst.foldLeft(Pair(List.empty[T],List.empty[T]))(comp)       
}

今回F#バージョンで型注釈を入れているがこれも省ける。

[要件のツボ]定義情報をEnterpriseArchitectのファイルに出力

2011-09-20(火) 22:08 — kanzaki

先々週の東京でのセミナーで「要件のツボ」の情報をEAにつなげた　という意見を沢山いただいた。

そこでセミナー後早速「要件のツボ」からEAへの出力プログラムを作り、先週の札幌での勉強会で紹介した。

札幌での勉強会ではEAと「要件のツボ」の両方で要件定義を行った。

参加者の方からは柔軟で表現力の高さではEAがいいけども、何もないところから定義するのは「要件のツボ」の方が定義内容に集中できて簡単だ。　という意見をいただいた。

セミナー終盤で「要件のツボ」からEAへ出力した結果を見せたところ、関心をもってもらうことができた。

要件のツボで初期の要件定義を行い、ある程度固まってきたところで、EAに移っていくのがいい　というストーリーが見えてきた。

EAにつなげれば設計工程にもつなぐことが出来、開発にスムーズにつなげられる。

ポイントは「要件のツボ」の情報構造をEA上のパッケージで「どのように再現するか」ということだった。

もともとRDRAはEAでのモデリングから生まれたもので、そのノウハウを使って「要件のツボ」を作った。

従って親和性は高かったが、EAから「要件のツボ」に情報を戻すときのことを考えると、検討すべき課題が幾つかあった。

しかし先週のセミナーでの反応から「要件のツボ」からの出力を優先させることにし、低いバージョン（Ver0.3）として公開することにした。

出力する情報は「要件のツボ」のプロトコル以外の全ての情報を出力した。

もう一つの課題は、つながりのある各定義情報をどのようなダイアグラムとして表示するか？　ということと　定義情報の配置の方法である。

まずはつながりのある定義情報を一つのダイアグラム上に全て表示することにし、後はEAの自動レイアウト機能に託すことにした。

EAの自動レイアウト機能がなかなかよい。

自分でモデリングするときには自動レイアウトはほとんど使ったことがなかったが、今回初めて使ってみて結構使えることを確認した。

[RDRA][要件のツボ]要件定義に整合性をもたせるためには　定義内容の確認

2011-09-02(金) 13:28 — kanzaki

前回は時系列にドキュメントを積み上げる方式の問題点をあげ、その改善として洗練化による要件定義の話題を扱った。

今回は同じ整合性でも、定義した内容の整合性について考えたい。

私は、単純に考えると　

　システムとは　「入出力のつじつまを合わせるための仕み」　　　

　　　と捉えている。

役に立つシステムとは、業務やユーザにとって価値のある結果が得られるように最適なタイミングで入出力を提供すること　だと考える。

要件定義においてシステム化の価値を明らかにし、そのためのシステム境界を明確にする。

これが最適なタイミングにおける入出力となる。

問題はここからである。

その入出力のつじつまをどのように合わすか？　

というのが本当の問題になる。

例えば

複数の画面が洗い出され、それらの画面が扱う情報とタイミングをどのように整理すればいいのか？

それらの画面が扱う情報が必要な情報を満たしているとどのように確認するか？

この他にも整合性を確認する方法が幾つかある。

これらの定義した内容のつじつまを合わせるのが整合性を確保することである。

RDRAではCRUDとプロトコルモデルというもので整合性を取る。

その他にも厳密ではないが要求との突き合わせや個々の定義のつながりをナビゲーティブに確認する方法などもある。

UMLを使った場合はCRUDは機能とデータの関連上にCRUDを記述し、プロトコルモデルはステートマシンを利用する。

「要件のツボ」ではCRUDもプロトコルも両方専用の機能として実現している。また、定義のつながりをグラフィカルに表示することや項目レベルの突き合わせ機能もある。

従来のセミナーでは概念的な説明が多かったが、来週のセミナーではこれらをUMLと要件のツボを使って整合性を向上させる方法を紹介したい

コンテンツ配信