ソフトウェア要求

要求工学の本

https://gyazo.com/2da4ce6f34a2071ea1a0ff89349bebde

要求工学を取り扱った本ではあるが、堅苦しい感じではなくアジャイル形のプロジェクトへの言及も多く、現代のWebエンジニアにも相当学びがある内容だった。

導入

https://gyazo.com/871ab3fc36f0ecc90cd8f2fa775cbfe7

ソフトウェアシステムを作るうえで最も難しい部分は、何を作るべきかを正確に決める部分である。」

手戻りには、全開発費の30 ~ 50%かかることが多い ( Shull, et al. 2002; GAO 2004 )

要求の誤りが手戻りコストの70 ~ 85%を占める ( Leffingwell 1997 )

https://gyazo.com/db22e8785597ebcefd5dfd5f786b9504

要求を引き出して、分析して機能要件とのギャップを解消しつつ、最終的にはレビューするというプロセス

ビジネスアナリスト

現代だとTechnical Project Managerとかとも近いなと思った

以下のことをするらしい

ビジネス要求を定義

要求へのアプローチの計画を立てる

プロジェクトのステークホルダーとユーザークラスを特定する

ユーザークラスは、ペルソナのようなもの

要求を引き出す

要求を分析する

要求を文書化する

要求を伝達する

要求の妥当性確認を主導する

要求の優先順位付けを促進する

要求を管理する

要求引き出し

要求を引き出すというのは何を作るかというのを正しく定義するためには、重要な工程。そのための技法として

インタビュー

ワークショップ

タイムボックスを設ける

あとで考えるための駐車場を用意しておく

数日間にわけて実施する (2 ~ 3日)

フォーカスグループ

ユーザー代表のグループと話す

観察 (例えば、使ってるユーザーをみるとか)

アンケート

ユーザーストーリーとユースケース

ユーザー要求は、2番目のレベルの要求である。プロジェクトの目標を設定するビジネス要求と、開発者が実装しなければならないものを記述する機能要求の間に位置する

要求の種類

1. ビジネス要求

2. ユーザー要求

3. 機能要求

4. 品質属性

ユースケース

システムと外部のアクターとの間の、アクターにとって価値のある結果をもたらすことのできる、一連の相互作用を記述するものである。

ユーザーストーリー

「新しい能力を望む人、通常のシステムのユーザーまたは顧客の観点から、フィーチャーを簡潔に記述したもの」(Cohn 2010)

https://gyazo.com/8f0f5829b9b64d6ef42aad92b8e9675a

ユースケースは、プロジェクトの参加者に、ユーザーストーリーを集めても提供できない構造と背景を提供する

ユーザーストーリーには構造の厳密さがない

ユーザーストーリーは簡潔だが、ユースケースの各要素に踏み込んで考えることでより深い要求の理解が可能

ユースケースアプローチ

ユーザー要求を調べるときには、一般的なユースケースからはじめて具体的な使用シナリオを作っていく。あるいは逆に、具体的なシナリオ例を一般化してユースケースにしてくこともある。

ユースケースの各シナリオは、テスト可能である必要がある (代替フロー、雨の日シナリオを含めて)

ビジネスルール

ビジネスルールは、ビジネスに属するものであり、それ自身はソフトウェア要求ではない。しかし、ルールを順守するためにシステムが保持しなければならない特性を決定するので豊富な要求の発生源になる。

https://gyazo.com/b83aa1a155de8b7c443616e2bcc0fad0

ビジネスルールは、プロダクト一般的なルールなので資産化されるべき

もっといえば、組織で一般化されるべき

ソフトウェア品質

品質属性は様々な仕組みで分類されてきた (DeGrace and Stahl 1993; IEEE 1998; ISO/IEC 2007; Miller 2009; ISO/IEC 2011)

外部品質

Availability (可用性)

Installability (導入可能性)

Integrity (完全性)

Interoperability (相互接続性)

Performance (性能)

Reliability (信頼性)

Robustness (堅牢性)

Safety (安全性)

Security (セキュリティ)

Usability (ユーザービリティ)

内部品質

Efficency (効率性)

Modifiability (修正可能性)

Portability (移植性 )

Reusability (再利用性)

Scalability (拡張性)

Verifiability (検証可能性)

感想