« 2007年7 月 | メイン | 2008年4 月 »

2008年3 月

2008年3 月26日 (水)

要求を可視化するための要求定義・要求仕様書の作り方

ソフトウェア開発が失敗するのは
1.  納入できなかった
2.  納入したが使われなかった
3.  納入され、使われたが、廃棄された
4.  納入されたが、変更した上で、使われた

これらの原因は以下のような要求仕様の問題として帰着できる

a.  要求仕様が不完全や曖昧で望まれるソフトウェアを実現できなかった
b.  要求仕様を満足するソフトウェアを開発したが、要求仕様が顧客の目標に合っていなかった
c.  要求仕様を満足するソフトウェアを開発したが、変化した顧客の目標に対してソフトウェアを修正できなかった
d.  要求仕様を満足するソフトウェアを開発し、変化した顧客の目標に対してソフトウェアを修正する必要があった

これに対処するのが要求工学の課題である

要求仕様とは与えられた要求を満足する仕様である。
仕様を確定したとしても、それが顧客の要求を満足する場合としない場合がある

要求は次のような要求特性を持つ

1. 一意性/正規化
 各要求は一度だけ説明される。他の要求または他の要求の機能には言及しない

2. 完全性
 要求仕様書には、システム定義に必要な要求に加え、顧客によって識別される全ての要求を含める。また矛盾がない。

3. システム境界の明確化
 要求の境界、範囲、および言葉の定義を明確にする。

4. 進化容易性
 要求仕様書のバージョンを管理することで、修正を明確にし、進化を容易にする

9. 粒度
 機能要求の粒度は機能階層に対応づける。大分類・中分類・小分類という風に詳細化する。

また次のような要求属性を明確にすることで要求分析を効率化できる

1. 識別子
 番号などを用いて要求を一意に識別する

2. 優先順位
 顧客は各要求の優先度を識別しなければならない。

3. 重要度
 分析者は各要求のクリティカリティを定義しなければならない。
 顧客視点では優先度が低くてもシステムを成立させるために重要なものもある。

4. 実現可能性
 技術的可能性、顧客にとっての環境変化の受容可能度、費用、法的リスクなど

  • 山本 修一郎
  • 定価 : ¥ 2,100
  • 発売日 : 2006/03
  • 出版社/メーカー : ソフトリサーチセンター
  • おすすめ度 : (3 reviews)
    システム素人なのにシステム開発を任された人、必携です
    参考になりました
    わかりやすさと論理のバランスが絶妙

2008年3 月 2日 (日)

BOOKOFF Access

ブックオフオンラインからデータを取ってくるための、RubyOnRailsプラグインを公開しました。

BOKKOFF ACCESS(英語)

自分が使いたいところしか作ってないので、月1くらいのニーズで作り込んでいきます。
それにしてもニーズがあるのだろうか?