ソフトウェアさかば

これから作るモヤモヤしているシステム。どうやってすっきりしていくか？
RDRAセミナーでそのヒントをいただきました。

要件定義

「要件」とはやらないといけないことと、やってはいけないことを示したものだと考えています。その幅が設計の自由度になります。

妙に詳細に書かれた要件は後工程の自由度を下げますし、大切な内容が抜けている要件は動かないシステムを生みます。コンパクトに必要な情報だけを示すことができれば、内容の確認も容易になりますので仕様の抜けも少なくなるでしょう。

RDRAとシステム地図

今回のセミナーの技法であるリレーション駆動要件定義(RDRA)ではUML記法の各種モデルを用いて要件を表現します。その全体像を示すのがシステム地図です。システム地図はこれらの要件を一覧可能な抽象度の高いモデルです。

RDRAでは、要求、利用シーン、ユースケース、機能、画面、データ、イベント、イベントデータ、外部システム、入出力、などでシステム地図を書いていきます。新規開発の場合は上に書いた順に要件を固めていきますが、既存システムのリプレスではデータモデルなどやり易いところから始めます。いずれの場合でも一度に深いところまでモデル化せず、色々なモデルで行ったり来たりしながら段階的に要件を定義していきます。

ワークショップ

ワークショップでは貸会議室を題材に、RDRAツール(ベータ版)を使ってシステム地図を作製しました。ある程度モデル化されていたので、比較的スムーズにシステム地図を書く事ができましたが、ある程度書き進めると補助的な画面を作るかどうか議論になりました。要件の構造が見える化される事で、決めておかないと行けない事がわかったのだと思います。

RDRAツールは軽くて使い易いものでした。作成済みのアイコンのオブジェクトを選択しておいて新しいオブジェクトを作成すると、自動的に線が引かれるところなど、使い易いと思いました。初心者なので、オブジェクトの種類を変える事が多かったので、これが簡単にできると良かったと思いました。

要件定義のポイント

要件定義が日本語で書かれていると、整理されていても見通しが悪く、全体を追いにくくなってしまいます。ワークショップではシステム地図で議論できたことからも、 RDRAのように要件を構造化して抽象度の高いレベルでの俯瞰や詳細な検討ができれば、全体が追い易く、要件の抜けや、一貫性、対称性なども容易に確認できるでしょう。

RDRAでシステム地図を書く際は実現可能性を検討しません。実現可能性は要件チームとは別にいるアーキテクチャチームが考えるそうです。最近は要件に合わせて色々な選択肢があるからとのこと。業務に近いレイヤだからでしょう。しかし、より低いレイヤのソフトウェアや特殊な非機能要件がある場合は実現できるかどうかが大きな問題なので、HOWの突き上げよろしく、アーキテクチャチームとの連携を密接にする必要があると思います。

要件がなかなか決まらないパターンの一つに実装イメージが浮かばないことがあります。イメージがないままに詳しく書こうとすれば、やらないといけない事や、やってはいけない事ではなく、イメージの一例を書いてしまい、設計の自由度をなくすことになりかねません。RDRAでは要件定義チームがアーキテクチャの基礎知識を持っていることが、前提になっているのだと思いました。

おわりに

システムのモヤモヤはステークホルダーが協力しなければ解決しないと思います。その時点でわかっている事をモデル化する事で、問題点や不明点が見える化されてモヤモヤは徐々に解決すると思います。

そこで大切なのは、人が見渡せる範囲で表現できる事です。今回学んだシステム地図は、要件の構造を適切な抽象度で示すことでコミュニケーションが可能です。要件定義を進める手がかりを少しずつあぶり出しながら、作業を進める事ができるでしょう。