要求工学とユーザビリティ工学の違い
「要件エンジニアリング」と「ユーザビリティエンジニアリング」の方法論の主な違いは何ですか？それらはどこで重なり、どこで重なりませんか？ 2つのアクティビティに共通するアクティビティと排他的なアクティビティはどれですか。
私たちは過去数年間、自社でSWE BOKを開発してきました。そこでは、次のような2つの分野が見られます。
- 要件エンジニアリングは、お客様の問題（のみ）を検討する最初の分野です。 （あなたがそれを知っていると思っていても）それは完全に解決策を無視しなければなりません。
- ユーザビリティエンジニアリングは、ソリューションを使用可能にする方法を考える必要があるため、ユーザビリティがソリューションの一部になることを保証する要件を定義します。
- それらは、ユーザビリティを保証する要件が定義されている部分でのみ重複します。
要件はそのような私たちの命名法で見られます：
- 機能要件
- 非機能要件
- 安全保障
- 使いやすさ
- 保守性
- ....（コンピュータのコンテキストで見つけられるかもしれないすべての非難
- プロジェクト条件（変更されない要件、より制約のようなもの）。
ご覧のとおり、使いやすさは機能以外の要件の一部です。
「要件エンジニアリング」と「ユーザビリティエンジニアリング」の方法論の主な違いは何だと思いますか
個人的には、これらを分離することはしません。私は多くの時間をプロジェクトのビジネスアナリストとしての活動に費やしており、可能な限り、ユーザビリティが主要な要件収集作業の一部であることを確認しています。それらは「インターフェース要件」や「UI要件」などのサブカテゴリにリストされる場合がありますが、最終結果は同じです-実行可能で検証可能なニーズの表現のリスト。
共通のアクティビティとは何か、排他的なアクティビティとは...
繰り返しますが、取り組みの大部分は非常に絡み合っているため、それらを分離することには価値がないと考えています。通常のアクティビティがすべて適用されます。
- 要件ステートメント
- 機能の詳細
- テストケース
- 開発者およびQAによる検証
編集：mliebeltが別のアプローチを投稿しているようです。これはおそらくここで述べる最も重要なことです。同じ開発店は2つないので、ローカルの状況で機能するものを実行してください。したがって、同じアプローチは2つありません。
私はmliebeltとGrayによる2つの返信を数回読みました。両方に部分的に同意します。 UEをソリューション指向、REを問題指向と定義するのは正しいと思いますが、現在の研究はそれらの共通部分に焦点を当てることを目的としています。
REの最近のリファレンス（例：Alan M. Daviの本：JERM）を見ると、適切な製品を開発するためには、製品/ソリューションを初期段階（つまりRE）から考慮することが推奨されています。
一方、最近では、より使い勝手の良い製品を開発するために、これら2つのコンセプトを組み合わせる取り組みが行われています。たとえば、A。Seffahらによる「人間中心のソフトウェアエンジニアリング」を見てください。 UEとSEの間のギャップを埋めることが主な焦点です。
したがって、以前はREとUEが別々に扱われていたが、今日では、REアクティビティにユーザビリティ要件（およびその結果としてのユーザビリティ関連アクティビティ、つまりUE）を含めることの重要性が認められている。特に、ユーザビリティ仕様の作成につながるUEでのアクティビティ。まだユーザビリティ評価は本質的にREの一部ではないと思います。