So-net無料ブログ作成

本のベストセラー

要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか? [プログラミング]

システム開発において「要求仕様書」の書き方は特に決められてこなかった。
実際には、いい加減に書かれた要求仕様書に沿って開発がすすめられ、設計やプログラミングの段階で仕様モレや誤解、仕様の衝突に気が付き、顧客に確認メールをしながら作業をすすめるような開発がおこなわれてきた。これでは工数の見積もりもできないし、開発期間がオーバーしたり、要求を満たすシステムが作れなかったりするのは当たり前。

筆者の統計によれば、テストから先で発生するバグの過半が要求に関するものである。
要求仕様書を適切に表現することで、途中で発生する変更要件を減らし、仕様モレや仕様の衝突によるバグも減らしていける。
筆者の経験によれば、仕様の変更率は1/5に減り、後半で発生する仕様変更による出戻り作業(修正箇所をソースから探し出す作業がだんだん長くなる)が減って、本来の設計をする時間を確保できるとしている。

要求仕様書とは、依頼者の「作ってほしい」意図を設計者に「わかってもらう」ための文書。
しかし「わかった」が一致していないことはよくあること。それを乗り越えるには「わかったこと」を自分の言葉で表現して伝えてみるしかない。
こうして出来上がった仕様書がベースラインとなる。FIXを求めて以降の変更は受け付けないという態度は顧客との敵対関係を招くし現実的ではない。最初にSpecifyできるレベルの仕様書をつくりそこをベースラインとする方が現実的だ。変更を持ち出されたときも、どのくらいの手間がかかるなどの説明がしやすい。

要求仕様書のレベルは関係者が特定(Specify)できるレベルで仕様化でき、「実現可能性」が見えるレベルのもの。関係者がそのシステムのドメイン(業務内容)について理解できているなら、その部分の細かい記述ははぶかれてもよい。また、「作るための文書」なので、新人にむけて書くときとベテランに向けて書くときでは粒度はちがっていい。

要求が適切に文章で表現されることで、本当に考えることができる。
 ・要求に最適な開発プロセスを設計できる
 ・機能などの仕様を実現する際のリスクの抽出がはかどる。
 ・要求仕様のサイズ(項目数)から以降の青果物のサイズ見積りを調整できる。
 ・ソフトウェアの設計と並行してテストケースの設計の入力となる。

これまでの要求仕様書は要求と仕様がわけられていなかった。
また、機能要求だけで、品質要求がない場合が多い。(出来上がってから反応が遅いなどのクレームがくる原因になる)開発言語や、ライフサイクルモデル、実装上の制限がない。などの欠陥があった。

要求仕様書の作成(要件開発)はスケジュールの管轄外にはいることが多いが、これではいつ終わるかわからないので、なるべく早く項目数を見積もって、スケジュールの管理下に置くことをすすめていた。
そしてベースライン設定後に発生する変更は要件管理と考える。


筆者の進めるUSDM((Universal Specification Describing Manner)はExcelを使った要求を表現する文書作成の方法で、この書き方を使いながら、要求を仕様化するポイントを解説している。

要求の役目は仕様を導出すること。
適切な要求には「範囲」がある。
要求は「動詞」で表現される。
要求は「理由」とセットで表現することで依頼者の思いがどこにあるかわかる。
必要なら「説明」をつける。(筆者は概のつく文書は役にたたないといっていた、またこれらの説明はあとで用語集になるといっていた)

要求には名前とNoを振り、その仕様には対応するNoを振る。
仕様であることを明示するチェックをつける。

カテゴリ化の例。階層図、コンテキスト図、機能分割、機器構成分割などの例。
品質要求が抜けやすいこと、ISOによる品質特性の一覧とそれに応じた品質要求の表現の例。
品質要求には機能に付随するものと、システム全体に属する品質要求がある。

要求が大きすぎるときには要求を階層化して範囲を狭める。
ポイントはその要求に含まれる「動詞」を押さえること。
例:メールをキーワード検索したい
階層化 メールをグループ化する
    キーワード検索する
    検索されたメールを表示する
    選択されたメールの内容を表示する
分割基準(時系列・構成分割・状態分割・共通分割)を組み合わせて分割の隙間がないように分割する。
MECEを活用し、もれなく、ダブらないように階層を揃えて分割する。階層は2階層くらいで止める方がよい。

仕様とは実現してほしいことを満たすべき「具体的な振る舞い」の記述。最終的にはプログラムのコードに変換されるもの。具体的であるから「検証可能」であるもの。
認定仕様・・・関係者の間で自明のこととしてSpecifyできているもの。チェックリストに認定仕様であることがわかる項目を設ける。
検証可能であることを確認するためにテストエンジニアによるレビューが行われると効果的。
USDMの書式では、要求と理由のあとに要求番号の後ろに子番号をつけて、仕様をいれていく、この番号がテスト仕様書にも使われ、要件管理の追跡手がかりになる。

要求の表現範囲が適切であると、仕様を引き出す作業ははかどる。
仕様化しにくいときには、要求をできるだけ混じりけのないグループ化して作るのも効果的。グループは5-9の範囲が適切で、それ以上なら要求が大きすぎる可能性がある。
グループ分けには、時系列・構成・状態が考えられる。
フローチャートで表現すると、完成されて見えるため、欠けているなにかに気が付きにくい。
仕様と要求が混在していることがあるので、その場合は、要求なのか仕様なのかはっきりさせて、階層を揃える。(仕様と要求が同じ階層にこないようにする)
普段から仕様なのか要求なのか考える訓練が必要。ふさわしい要求をたてることで仕様モレを防ぐことができる。

仕様の表現には、ペースト作文は使わず、条件分岐が多いときにはデシジョンテーブルやPADフローを使って表現する。
否定表現に注意。否定表現ではIf文の片方しか書いてないことが多い。Elseのときの動作がないことに気が付くようにする。
等やetcは使わない。具体例をすべてかくか、決める日付を書いておく。

FIXではなく賞味期限という概念を持つ。
「その使用は何に依存しているか」「なにが変われば、この仕様書が変化するのか」を顧客と考えておくこと、要求仕様書の中に決めたことを明記しておくほうがいい。

品質要求の仕様化
「保守性」には独特の設計技術がひつようになる。品質要求の仕様化は設計を誘導する力をもつ。
パフォーマンスや、対故障性、保守性の品質要求が考えられるが、なかにはテストでは確認できないものがある。

確定しない仕様は5%以下なら日程を優先する、積み残しは「変更制御」プロセスで対応する。
その場合も、その時点までで明らかになったこと、確認中のことなどは記述しておく。また未確定になっていること、いずれ合意することを依頼者との間で認識をあわせておくこと。

設計情報
仕様を書いている最中に設計方法(実現方法)として浮かんでくるものは、設計情報としてまとめておく(Excelの別シートなどを使う)その場で立ち止まって実現方法をかんがえるのは避ける。


Excelによる仕様化
①要求書をつくる。(要求と理由説明が付いたもの)このとき仕様がうかんだから少し下にいれておく
②要求TMに展開する。要求の後ろの列にモジュール(適当な単位、タスクやソースファイルなど)列をつくり、要求を実現している箇所を書く。
要求TMを使うことで要求と仕様が結びついて影響範囲がわかりやすくなる。
Excelを使うことで自在に列を増やし、サイズ見積りなどにも使える。
注意は文章を短くする心理がはたらくので、普通の文章を書くようこころがけること。



派生開発について
派生開発の特徴は、ベースのソースコードがあり、そこに追加や修正、削除を加えたらり、移植したりするが、ソースコードを十分理解する時間はない。

たいていの場合、ソースコードを読みながら関係すると思われるところを手当たり次第に変更していくが、部分理解でやっているため、あとになって修正をやり直す作業が多くなったり、思わぬところにバグがでて修正作業に追われ、納期をはずすことになる。

派生開発の要求は、変更要求と機能追加があり、要求仕様書もこの二つがある。
基本的には機能追加は新規の要求仕様書と同じになる。
変更要求では「差分」が要求。変更前と変更後の併記をして差分がわかるように表現するのがポイント。
この場合も「理由」をたてることで本当の変更要求をはずさなくなる。

ソースコードは仕様が表現されたものであり、ソースコードを変更するということは仕様を変更するということ。
変更要求仕様書をもとに実際のソースコードからスペックアウトを行い(TMを作成)と、変更設計書を作成する。そこで変更箇所を確認し、ソースコードの変更はすべての変更箇所が把握できてから行う。
そうすることで、度重なる修正のたびに、なんのための変更だったのか思い出す無駄な工程が省かれ、しかも変更箇所がはっきりしているので、バグが発生したときの対応もしやすくなる。

機能追加の場合も、新規用を追加するという変更要求は立つ。

移植は散らばった処理をかき集めて移植することが多いので、変更より難しいことがある。
移植元の変更も変更要求仕様で扱って、移植先の変更とセットにする方法がある。

削除要求も変更仕様として扱い、影響範囲を確認する必要がある。



画面仕様書の問題点
動くものがあると、依頼者もモノにつられて機能モレに気が付きにくい。
範囲や振る舞いなど必要な仕様がもれることが多い。
画面仕様書でも通常の要求仕様の形で記述して、仕様モレを防ぐほうがよい。
また、画面操作全体に対する要求が見落とされることがある。
画面推移図でかならず動きを表す。多いときには階層化する。
画面仕様書と機能仕様所が重複しないよう、画面仕様書には○○機能を呼び出すなどと記述する。


ヒアリングの注意
要求の合理性、願望、他の要求とのバランスを考える必要があるのでヒアリングで解消していく。
最初に「システムの目的」を確認する。
顧客側の最終責任者や機能ごとの担当者を確認する。
要求仕様書を作成するのが設計者側なら
 ・要求と仕様を分けた考え方や表現方法を説明し、理解してもらう。
 ・フォーマットの合意
 ・ベースライン設定の意味を理解してもらう
 ・要件管理について説明し合意しておく
要求仕様書を依頼者が作成している場合は
 ・構成や特徴を確認
 ・仕様の不足を補う工程を挟むことを確認
 ・設計側で要求仕様書を理解する方法や表現を説明する

依頼者の希望でスケジュールを立てない。あくまで要求仕様の項目数を前提としてサイズ見積りをすべき。その際要件変更の分も考えておくべき。

要求仕様書の体系を示し、ヒアリングの範囲を事前に知らせておく。
Excelのフォーマットに慣れてもらう。
またヒアリングしたことは要求仕様書の体系のなかに収める。そうでないと仕様モレや仕様の衝突に気が付けない。理由を考えることで顧客が発した仕様だけを実現しようとして仕様モレを起こす事態は避けられる。
品質要求のヒアリングもわすれないでする。品質は設計で織り込まないといけないので、事前にわかっていなければならない。
未決定項目を含むベースライン設定を合意しておく。
仕様化作業は顧客を巻き込むことが必須。双方がわかった要求仕様書でなければ意味がない。



仕様の変更がおこるのはやむ負えないこと。
事前の適切な仕様化と要件管理のプロセスを持つことで対応する。
仕様化段階で顧客を巻き込み、要求仕様書を自分の青果物の一部とおもってもらうことが大事。
また、最初のサイズ見積りで合理的であると説得力がある。
また、仕様変更を実施する時期などもコントロールしやすい。
仕様の変更率=変更仕様件数/総仕様件数×100 これが3-5%になるのが目標。著者の経験ではUSDMで7%前後にまで落とせるという。

仕様化の効果を計測することは必須。そしてPDCAサイクルに乗せる。中途半端だと効果は期待できない。
「計測されないものは、改善されない」
計測データとして感がられるもの
それぞれの工数・・・ヒアリング、要求抽出、仕様化、ピアレビュー
指摘件数やバグ件数・・・ピアレビュー、ベースライン設定時仕様数、要件管理の変更件数、設計者からの問い合わせ数、仕様によるバグ件数
これらを組み合わせることで狙い通りの結果になったところ、期待した効果を得られなかったところが見えてくる。
また、平均的な工数より減らせた部分を獲得時間として表す方法もある。
バグから学ぶのは「どうすればこの仕様モレはなかったのか」と考えること。仕様関係のバグを整理分類すると書かれている仕様の特徴がでてくる。個別のバグ事例から対策を感がることで学習効果が得られる。


この仕様化技術はリスク管理にも応用できる。
要求→リスク
理由→要因
仕様→軽減措置
と考えれば良い。
リスクと要因が混同されていることが多いのでわけて考え、具体的な行動(軽減措置)を考える。
「仕様化されない要求は実現されない」



要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?

要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?

  • 作者: 清水 吉男
  • 出版社/メーカー: 技術評論社
  • 発売日: 2005/10/07
  • メディア: 単行本



nice!(0)  コメント(0)  トラックバック(0) 

nice! 0

コメント 0

トラックバック 0


この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。