この連載では「要件定義は洗練化を繰り返して進めていく」と何度か説明してきました。しかし「どうやって管理するの？？」と頭に「？」マークが浮かんだ読者も多いことと思います。また要件定義工程の終盤になって上位のステークホルダーに「なんでここはこうなったんだ！」という指摘により大きく方針転換し、要件定義が予定通り終わらなかった経験がある方もいるかと思います。

　要件をつなげて定義しただけでは要件の精度を向上させることはできません。登録した情報を様々な視点で確認することで整合性や網羅性を向上させることができます。今回は「要件を分析する」「要件を検証する」「要求を使って要件定義に方向性を与える」「ツールを使って議論する」の4つの場面で精度をあげる方法を紹介します。

　普段UMLを使っていない方に、UMLを使った要件定義の話をしてもなかなか受け入れられません。重要なことは要件の定義であり、UMLの表記法やツールの使い方を覚えることではありません。そこで今回から、UMLを使わずに簡単な入力でスムーズに要件定義の情報をまとめられる「要件のツボ」を紹介します。

　ドキュメントを一つ一つ完成させて進捗を管理する方式が成果物ベースの管理方式です。進捗の判断が明確で管理が容易な反面、成果物の完成イコール要件の決定となると問題を引き起こします。そこで今回は成果物ベースで各メンバーが並行的に作業する従来の方式とはまったく逆の、メンバーが集まり共同して成果物を作成する進め方をご紹介します。

　前回は要件定義には構造があり、その構造を使うことで要件をスムーズに定義できることを紹介しました。今回はその構造に沿った具体的な定義の方法をご紹介します。

　『要件定義の勘どころ』の記事を書いた後、私のもとには「より具体的な話を聞きたい」「実際のプロジェクトで起こる問題にどのように応用するのか」という声をいただきました。そこで今回は私が策定した「リレーションシップ駆動要件分析（RDRA）」をもとに、より具体的に要件定義を行う方法について連載します。