読者です 読者をやめる 読者になる 読者になる

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

要件定義 基本設計

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

要求とは?

 なんか、以前にも書いたような気がしますが、現状の理解を書いてみます。
 要求とは、顧客が提供するサービスまたはシステムに対して実現したいと思っていること、と言えます。そして、この要求はRFPに書かれていたりするわけですが、この要求にはレベルがあります。

Lv1 サービスレベルの要求

 これは、もっとも抽象度が高く顧客がエンドユーザに提供したいサービスに対する要求です。新規サービスにおいては、顧客自身もその最終形は見えていない状況から始まることもあります。このレベルではサービスがどのようなシステムによって実現されているのかは関係がありません。

Lv2 システムレベルの要求

 実際には顧客は既にサービスを提供しており、そのための複数のシステムが存在しています。そのシステムに対する追加や変更に対する要求がこのレベルの要求です。サービスレベルで実現したい内容をシステムレベルに落とした要求ということもできます。

Lv3 仕様レベルの要求

 これは◯◯画面の××を△△に変えたい、というような仕様レベルに対する要求です。俗にいう仕様変更とはこのレベルに対する要求が変わったという意味です。システムが実現している仕様を顧客も理解しており、その仕様に対して新しい要求、変更要求が出てきます。

問題点は?

 このように実際には要求にはレベルがあるのですが、そのレベルが入り交じって顧客からは出てきます。さらに自分たちが要求を分析する際に、どのレベルの要求なのか意識しないと、レベルがバラバラで混乱してきてしまいます。

では、どうすればよいの?

 今、どのレベルの要求を扱っているのか?帽子をかぶり直して意識を切り替えながら要求を扱いましょう。アリスター・コーバーンのユースケースに対するアイコン(雲、凧、海面)と同じです。

仕様とは?

 要求に制限を設けることで、その実現方式を決定するための決め事が仕様です。仕様は要求から導出されます。よって、仕様にもサービスレベルの仕様とシステムレベルの仕様があります。

 例えば、システムレベルの要求として

  • 「ユーザには画面の文字の大きさをユーザの好みによって変えられるようにしたい」

 という要求があるとします。この要求に制限を設けて、実際にどのように要求を実現するのかを決めるのが仕様ですので、

  • 「文字の大きさに大、中、小の3段階設けて、その大きさを大=16Pt、中=12Pt、小=8Ptとする。」

 が仕様になります。5段階にしてもよいです。それは仕様をどうするかという話であり、要求は変わりません。これが要求と仕様の違いになります。

 ユースケースはまた今度。