私のプロジェクトの1つで、ユーザー調査がまもなく完了し、次のタスクはペルソナの作成とユーザー要件ドキュメントの生成です。これは私の最初のUXプロジェクトの1つであるため、私の提案は、主に A UXデザインのプロジェクトガイド 。この本はユーザーの要件について述べていますが、ユーザーの見た目については詳しく説明していません。
以前のソフトウェア開発のキャリアでは、非常に形式的にCMMIスタイル(「システムは...」)で書き出され、アジャイルプロジェクトのwikiスタイルの機能的な技術仕様はそれほど正式ではない要件に対処しました。このUX再設計プロジェクトでユーザーの要件にどのようにアプローチするかを考えています。
このクライアントは非公式なグループなので、彼らが情報を読んで読めなくなるほどの情報で圧倒したくない。
したがって、いくつかの質問:
UXユーザー要件のドキュメントで、どのカテゴリの情報を詳しく説明する必要がありますか? (再設計固有のものはありますか?)
ユーザー調査が提案で合意されていない機能を求めている場合、ユーザー要件はこれにどのように対処する必要がありますか?
オンラインのUXユーザー要件ドキュメントの無料テンプレートはありますか?
ユーザー要件の実行方法を詳しく説明した本はありますか? (私はオンラインテンプレートを非常に好みます。それは無料であり、ドキュメントをより早く開始できます。)
Mike Cohnはブログに優れた記事を公開し、 User Stories for Requirements の使用を主張しています。なぜなら
- ユーザーストーリーは、言葉によるコミュニケーションを強調します[開発者と顧客の間]
- それらはプロジェクト計画ですぐに使用できます。 [...]一方、ユースケースは一般に大きすぎて、有用な推定値を得ることができません。
- ユーザーストーリーにより、チームは詳細の収集を延期することができます。
ユーザーストーリーが書き込まれます この形式(質問3):
-タイプのユーザー-として、私は-いくつかの目標-が欲しいので、-何らかの理由-。
彼の記事には、「従来の」使用例の2つの例があります。 2つ目は、インターフェースまたは相互作用の要件を説明することです。このようにして、ISO規格に準拠した要件を記述する方法を学びました。彼はまた、IEEE 830仕様「システムは...」についても言及していますが、その欠点も示しています。
このタイプの考え方は、ソフトウェアが目的のユーザーの目標を達成するときではなく、要件のリストを満たしたときに完成するという信念を強めます
記事の最後には、より深く読むための参考資料がいくつかあります。 (質問4)
。
「使いやすい」や「インターフェースの反応が速い」など、いくつかの非機能要件があると思います。
- ユーザーとして、私はサイトにアクセスしようとする時間の99.999%が利用できるようにしたいので、イライラしたり、使用する別のサイトを見つけたりしません。
- ラテン語を話す人として、いつかあなたのソフトウェアを実行したいと思うかもしれません。
Mikeはこのトピックを ユーザーストーリーとしての非機能要件 に関する記事で取り上げています。コメントも読むことをお勧めします。アジャイルプロジェクトでコメントを正しく実装する方法について説明しています。
質問2:ユーザーの追加のニーズ(いわゆる機能)を、ユーザーストーリーの形式で追加の章にまとめます。可能な場合は緊急度を教えてください。すべてのユーザーストーリーの再優先順位付けについて、それを要求したユーザーのパーセンテージまたは測定された欲求スコアによって、意思決定支援を提供できる場合があります。