要件定義書にUMLを使ってみよう

概要

2024年Qiitaのアドベントカレンダー、4回目の投稿になりますので、よろしくお願いします。今回もタイトル通り要件定義書とUMLのお話です。
要件定義書の書き方は色々なスタイルや会社の方針等あるので、この記事の内容は一つの参考例として読んでもらえれば良いかなと思います。初めて要件定義書を書く際に「何をどう書いて良いか分からない」との声をよく聞くので、「こんな書き方もあるよ」くらいな感じです。

UMLについて

私が要件定義書を書く時のベースにしているのがUMLです。UMLとは「統一モデリング言語」と言い、システム設計を視覚的に分かるよう表現することです、、、多分。

このUMLに従うことのメリットとして、システムの構造をエンジニア間で共有しやすいことが挙げられますが、非エンジニアにも理解しやすいというメリットもあります。
要件定義書と、あと基本設計ですね〜誰が読むかというと、エンジニアはもちろん、クライアントさんですよね。クライアントさんにも理解しやすいように、できるだけUMLで表現しようとしています。

ただ、UMLのダイアグラムは15個くらいあるので、どれをどう使って良いか分からないかなと思います。
私の場合ですが、要件定義段階では、クラス図、ユースケース図、アクティビティ図、配置図あたりをよく使います。厳格に作り方の規約を守っているわけではなく、みんなが理解できれば良いくらいの感覚かな。

ここで詳しい記載方法とかは書きませんので、ぜひ調べてみてください。

要件定義書にUMLを当てはめてみる

まず要件定義書を書く前はクライアントにヒアリングを行います。まぁ、ざっくりとどんな事をしたいかを聞いて、要件定義書に落とし込んで、「こんな感じでいかがでしょうか」とクライアントに提示していく。こんな流れで要件を固めていきます。
ちなみに要件定義から設計、構築まで全部自分で行うことが前提で、小規模〜中規模の開発でと考えていますので、大規模でウォーターフォール形式の進め方は合わないかなぁと感じています。

システム概要

ここはシステム開発に至った背景や目的と目標を記載します。まぁ、ここはクライアントさんから聞いた事を形式に合わせて書けば良いかなぁと。
あと、プロジェクトの組織体系もこの辺りに書いていますね〜この辺りはネットにあるサンプルを参考に。

登場人物の定義（ユースケース図のアクター定義）

システムの登場人物、外部システムを含めてアクターを洗い出して定義します。ユースケースの粒度は粗くて良いので、アクターを定義する事を優先にします。

アクター	概要	備考
管理者	本システムの管理を行う	主に○○社の情報システム部
ユーザー	本システムを利用する
管理システム	ユーザー情報を保存する	AWS上で稼働中

ざっくりとこんな感じです。
まぁユースケース図でなくても良く、アクターとシステム開発の範囲を定義できるようにします。

この辺りから、クライアントさんを含めて、このプロジェクトに関わっているメンバー全員にドキュメントに記載している単語だけを使うよう強めに周知していきましょう。
使っていない単語が出た場合は、必ず認識を確認し、必要であればドキュメントに追記していきます。使う言葉を統一して、認識のズレをなくすようにしましょう。

クラス図

クライアントさんに要件をヒアリングしながら、実現したいシステムをモデリングしてクラス図を作成します。

上記はざっくりし過ぎですが、クラス図を使うことで、システムの全体概要がわかるので、クライアントさんにも見方を説明し理解してもらい、プロジェクトを進める上でクラス図をベースに話を進めるようにします。
ですので、要件定義書に記載しておきましょう。

良いシステムは良いクラス図があって出来上がると考えていますので、時間をかけてでも納得のいくものを設計してください。これがシステムのキモになります。
最初から振る舞いは書けないかなと思うので分かり次第記載していきます。

機能要件（ユースケース図）

機能要件もUMLのユースケース図で対応します。要件定義レベルですので、ユースケースの粒度はクライアントさんとのヒアリング次第かなと。
上記の「ユーザーを管理する」を機能要件のユースケースで表現すると、ざっくりこんな感じかなと。

機能	概要	対象アクター
ユーザーを閲覧する	登録したユーザーを一覧表示する機能	管理者
ユーザーを登録する	本システムを利用するユーザーを登録する機能	ユーザー・管理システム
ユーザーを更新する	本システムを利用中のユーザー情報を更新する機能	ユーザー・管理システム

ユースケースの粒度によりますが、機能要件は上記のように記載していっています。
ここもクライアントさんとエンジニアの認識が合わせる事を優先して記載していきます。

業務フロー（アクティビティ図）

業務のプロセスを図に表したものになります。システムを導入した際の業務をクライアントさんと認識合わせするために使います。業務フローにはUMLでいうアクティビティ図を使いますが、アクティビティ図を使っている意識はないです。
システム導入前後の業務フローを用意しておけば、システム化した箇所が視覚的に分かりやすくクライアントさんの理解が進みやすいのでオススメです。
ざっくりとこんな感じに記載していき、とりあえず漏れなく表現し、認識合わせしていきましょう。

非機能要件

UMLはあまり使わないところですが、運用やインフラに関わる重要な箇所です。
この辺りは非機能要件グレードを参考に内容を詰めていってください。

最後に

要件定義とUMLの関わり方を記載していきましたが、基本設計やその後の認識合わせでも全然使います。UMLは変更も容易かと思っているのでアジャイル的な進め方のドキュメントに向いているとも勝手に思っています。
私はUMLベースで要件定義や設計を考えていますので、プロジェクトで一緒になった際は、ぜひこの認識でお話ししてみてください。
雑多に書いた記事なのでご指摘等あるかと思いますが、またコメントをいただけると幸いですので、よろしくお願いします。