ソフトウェアの品質要件の優先順位付け

すべての品質特性に対して最大値を設定することはできません。どれが最も重要かを判断する方法は次のとおりです。

Freepik 上の Creativeart による画像

理想的な世界では、すべてのソフトウェア製品がすべての品質特性で最大の値を示します。このシステムは常に利用可能であり、失敗することはなく、常に正しい結果を即座に提供し、すべての不正アクセスをブロックし、ユーザーを混乱させることはありません。それは素晴らしいことだと思いませんか？

しかし実際には、特定の属性間のトレードオフと競合により、すべてを同時に最適化することは不可能になります。プロジェクトの成功にとってどの属性が最も重要かを判断し、設計者が適切な選択をできるように、それらの属性に対する具体的な目標を述べる必要があります。この記事では、コンサルタントの意見をもとに、プロジェクトにとって最も重要な品質属性を特定して指定するためのアプローチについて説明します。 ジム・ブロッソーのメソッド。

ステップ 1: 大まかな分類から始める

表 1 にリストされているような、考慮すべき品質属性の豊富なセットから始めます。 他にもたくさんただし、これらはソフトウェアを含む製品に最も一般的に適用される属性です。この広範な出発点により、重要な品質側面を見落とす可能性が低くなります。

表 1. いくつかの一般的なソフトウェア品質属性

ステップ 2: リストを減らす

さまざまな関係者を巻き込んで、どの属性が製品にとって重要である可能性があるかを評価します。たとえば、旅行者向けの空港チェックイン キオスクは、使いやすさ (ほとんどのユーザーが頻繁に遭遇することがないため) とセキュリティ (支払いを処理する必要があるため) を重視する必要があります。プロジェクトの成功にあまり影響を与えない属性については、これ以上考慮する必要はありません。

ステップ 3: 属性に優先順位を付ける

関連する属性に優先順位を付けることで、今後の引き出しに関する議論の焦点が決まります。ペアごとのランキング比較は、このような項目の小さなリストを使用して効率的に機能します。図 1 に使用方法を示します。 Jim Brosseau のスプレッドシート 空港チェックインキオスクの品質特性を評価します。

図 1. 空港チェックイン キオスクの品質属性の優先順位付けのサンプル。

2 つの属性の交点にある各セルについて、「これらの属性のうち 1 つだけを持つことができるとしたら、どれを採用しますか?」と自問してください。小なり記号の入力 (

たとえば、可用性と整合性を比較すると、整合性の方が重要であると結論付けます。キオスクが利用できない場合、乗客はデスク係員にチェックインすることができますが、キオスクに正しい情報が表示されない場合、乗客は非常に不満を抱くでしょう。可用性と整合性の交差点のセルにキャレットを置き、整合性がより重要であることを示しました。

スプレッドシートは、2 番目の列に示されているように、各属性の相対スコアを計算します。この図では、セキュリティがスコア 7 で最も重要で、次に完全性がスコア 6、使いやすさがスコア 5 で続きます。他の要素も確かに成功に貢献しますが、チェックインの途中でキオスクがクラッシュするのは良くないため、信頼性が重要です。実際には、すべての品質属性を最優先にできるわけではありません。

優先順位付けは、主要な属性に焦点を当てて抽出するのに役立ち、矛盾する要件に遭遇した場合の対応方法を知るのに役立ちます。この例では、特定のパフォーマンス目標といくつかの特定のセキュリティ目標を達成したいという願望を引き出すことができます。セキュリティ層を追加するとトランザクションが遅くなる可能性があるため、これら 2 つの属性が衝突する可能性があります。優先順位付けの結果、パフォーマンス (スコア 4) よりもセキュリティ (スコア 7) の方が重要であることが判明したため、そのような競合の解決にはセキュリティを優先する必要があります。

ステップ 4: 各属性に対する具体的な期待を引き出す

ユーザーは、「相互運用性の要件は何ですか?」などの質問にどう答えればよいのかわかりません。または「ソフトウェアはどの程度信頼できる必要がありますか?」ビジネス アナリストは、ユーザーの期待を調査し、開発者が魅力的な製品を作成するのに役立つ特定の品質要件につながる質問をする必要があります。

たとえば、発明者が提出した特許出願を管理する情報システムのパフォーマンスに関するユーザーの期待を理解するために、BA が尋ねる可能性のあるいくつかの質問を次に示します。

1. クエリに対する典型的な特許出願の検索の妥当な応答時間はどれくらいですか?
2. 一般的なクエリの場合、ユーザーは許容できない応答時間はどれくらいだと考えるでしょうか?
3. 平均して何人の同時ユーザーが予想されますか?
4. 予想される同時ユーザーの最大数はどれくらいですか?
5. 1 日、週、月、または年間のうち、使用量が通常よりもはるかに多いのはどの時間帯ですか?

許容できないパフォーマンス、セキュリティ、または信頼性を構成するものをユーザーに尋ねることを検討してください。つまり、権限のないユーザーによるファイルの変更を許可するなど、ユーザーの品質に対する期待に反するシステム プロパティを指定します。許容できない特性を定義すると、システムにそれらの特性を強制的に示すテストを考案できます。強制できなければ、おそらく品質目標は達成されているでしょう。

ステップ 5: 適切に構造化された品質要件を指定する

「システムはユーザーフレンドリーであること」や「システムは 24 時間 365 日完全に利用可能であること」などの単純な品質要件は役に立ちません。前者はあまりにも主観的で曖昧です。後者はほとんど現実的でなく、必要性もありません。どちらも測定可能ではありません。したがって、このプロセスの最後のステップは、各品質属性に関して引き出された情報から、具体的で検証可能な要件を作成することです。

品質要件を記述するときは、SMART ニーモニックを念頭に置いて、具体的、測定可能、達成可能、関連性があり、時間に敏感なものにしてください。品質要件が測定可能でない場合、それを達成したかどうかを判断することはできません。 P言語と呼ばれる記法は、これを容易にする優れたツールです。 品質属性要件の正確な仕様。

ユーザーの品質に対する期待を満たすことは、ソフトウェア プロジェクトの成功に大きく貢献します。賢明なビジネス アナリストは、システムの機能要件を引き出すのと同じくらい、品質特性を熱心に調査します。

著者: カール・ウィーガースとジョイ・ビーティ

この記事は以下から転載されています ソフトウェア要件、第 3 版 カール・ウィーガースとジョイ・ビーティ著。カールは他にも数多くの本の著者です。 ソフトウェア要件の要点 (キャンディス・ホカンソンと)、 ソフトウェア開発パール、 日常のものの無思慮なデザイン、 そして 成功するビジネス分析コンサルティング。 Karl は、品質属性を優先するためのツールを共有してくれた Jim Brosseau に感謝します。