学習の内容と経緯

読書感想文：「ソフトウェア要求」10, 11, 12, 13 章の続き。

面白かったポイントと考察

ソフトウェアの品質特性

下記のような品質特性をリストアップして、作成するソフトウェアがどの品質特性を優先するか事前に話し合っておけるとタスクのプライオリティが決めやすい。 外部品質（ソフトウェアの実行時に識別可能な特性）は下記の通りである。

• 可用性
• 導入可能性
• 完全性
• 相互接続性
• 性能
• 信頼性
• 堅牢性
• 安全性
• セキュリティ
• ユーザビリティ

内部品質（外部品質に属さない特性）は下記の通りである。

• 効率性
• 修正可能性
• 移植性
• 再利用性
• 拡張性
• 検証可能性

品質要求を書くときの SMART

SMART とは、下記の引用に記載された特性である。 これらの特性を満たすことで、開発者が妥当な要求に向かって開発する状況を作れる。

品質要求を書くときには、SMART にすることを覚えておこう。つまり、具体的（Specific）で、測定可能（Measurable）で、達成可能（Attainable）で、関連性（Relevant）があり、時間を意識する（Time-sensitive）のだ。

テスト担当者がテストを設計できるような客観的な要求が大事

自分たちが望んでいる要求が達成しているかを最終的に判断できなければならない。 基本的にこれを判断するのは、受け入れテストであることが多い。 つまり、最終的に受け入れテストの担当者が要求をみて受け入れ判断ができるようなテスト設計ができれば、検証可能な良い要求だと言えると考えた。

外部品質特性における定量指標の一覧

外部品質の要求を検証可能にするため、よく使用されているプラクティスや指標がある。 例えば、可用性でいうと、平均故障間隔（MTBF）や平均修復時間（MTTR）などがある。 SMART に記述するために、これらのよく使用される定量指標を活用できると検証可能な要求になると考えた。

使い捨て型と進化型のプロトタイプをうまく使い分けながら効率的な開発をする

プロトタイピングには、使い捨て型と進化形があり、それぞれの特徴を理解して使い分けることが重要である。 使い捨て型のプロトタイプは、本番環境で使用しないことを前提に、要求の不備を早く見つけるために使用する。 クイックアンドダーティに検証を行える一方で、本番環境に流用できない。そのため、使い捨て型のプロトタイプを作ることばかりを行うといつまでたってもソフトウェアが完成しなくなるので、あらかじめイテレーションの回数を制限するなど時間をかけすぎない工夫が必要である。
進化型のプロトタイプは、本番環境でプロトタイプのリソースを流用する前提で作るので、うまくハマれば手戻りコストは少ない。ただし、検証可能な環境を作るまで時間がかかるので使い捨てプロトタイプより高速にイテレーションを回せない。

参考文献

(1) カール ウィーガーズ；ジョイ ビーティ. ソフトウェア要求　第 3 版 (Japanese Edition), 日経 BP 社. Kindle Edition.