要求や要件を定義しよう

『要求』は『仕様』を考える出発点

例えば皆さんが、スマートフォンを自分で購入するときに、『通話料金を安くしたい』とか、『スマホゲームをたくさんやってもパケ死しない』とか、『ゲームや映像がサクサク動いてほしい』とか、そういったことを考えつつ金額と相談をしながらスマートフォンを購入すると思います。こうした、『〇〇したい』とか『△△であってほしい』というものが、『要求』です。

アプリケーションでも、当然このような『要求』はたくさんあります。スマートフォン自体が汎用のコンピューターですから、『〇〇に使いたい』という要求があるなら、その要求を満たすアプリケーションを探して使うと思います。例えば、『ダイエットしたい』という要望に対して、要求は『毎日の食事のログを取りたい』とか、『体重のグラフを見たい』とか、そういうものになります。場合によっては、『分析結果から、自分がどれくらいおいしいものを食べていいのか知りたい』なんていう要求もあったりすると、それに合致するアプリは少々お値段が高くなるかもしれません。

アプリケーションを作成するのは、こうした皆さんがユーザーとして当然持つだろう『要求』をまず最初に明らかにすることから始まります。ここでは、先ほどの『ダイエットしたい』というところから、アプリケーションの要求を考えて行きたいと思います。

『要求』は『どのように使われるのか』の定義から

ダイエットで必要なことは、次のように言われています。

明確な目標を決めること。長期目標だけでなく、短期的な目標も立てること。
無理な目標設定でないこと。
目標と現状をよく把握して、『行動』として表現すること。
何より、楽しくやること（コミュニケーションを取りながら）

これらをサポートするようなアプリケーションを作るとなると、どのような要求がユーザーからあるでしょうか？この部分については、ユーザーが想定するアイディアから起こされる必要があります。一例として考えてみると、

目標体重と、期間、そこから逆算しての週間目標体重の設定ができるようにする。
目標体重の異常設定をチェックする。特に、進捗が悪い場合に、期間や目標体重の再設定を促す。
筋トレや有酸素運動、食事のログをとれるようにする。
親に成果を見てもらって、食事の調整や激励をもらえるようにする。ただし、直接的には見せたくない（点数化する）。

要求を要件に変える: 機能要件と非機能要件

少し難しい話ですが、『要求』から作成するべき『要件』を定義するときには、『○○してほしい』と明確に提示されている要件と、一般的に見て、『〇〇じゃないといけない』というような暗黙的な要件があります。前者を『機能要件』と呼び、後者を『非機能要件』と言ったりします。特に、『非機能要件』は、皆さんが作るプログラム上の問題よりは、使うルールやスマートフォンのスペックなど、作る部分以外のところに要求があるものとなることが多いので、注意が必要です。

『機能要件』とは、特に『実装、搭載すべき機能』に関する要件のことを言います。ソフトウエアを作る場合、こちらが主目的になります。例えば、『何がしたいのか』、また『何ができないと困るのか』など、そのシステムが必ず満たすべき要件のことを指します。

今回の要求から『機能要件』として定義できるものは以下の通りです。

個人情報設定画面（現在体重、記録日時、目標体重、期間）
週間目標体重設定クラス（現在体重と目標体重、期間からの計算、しきい値設定による異常設定検出）
日間ログ書き込み画面（データ型は表形式）
日間ログ表示画面（折れ線グラフ形式、棒グラフ形式）
成果の点数化クラス（日間ログ内の情報から、1日の行動を点数化して合算）
親通知クラス（メール送信、点数と現在体重、目標への進捗との比較）
親通知情報画面（自分確認用） …等。

『非機能要件』とは、そのシステムがどれだけの性能を持っているかなど、主目的（機能要件）以外での要件のことを言います。この非機能要件については、ユーザ自身も意識していない場合や、暗黙の了解事項として期待している場合があるため、開発者とユーザ間で入念な話し合いをして、ユーザがそのシステムに期待している、求めている品質を明らかにし、満たす必要が有ります。今回の非機能要件の例としては、次の通りです。

定期的なアップデートの計画
情報のセキュリティのための要件 …等

使用シーンからの要件の定義: ユースケース図

先の項目で、機能要件を定義しました。要求もありますので、これを分かりやすい図に書いていくと、ほかの人に説明がしやすいです。この時、アニメーションで、かわいいイラストで、見栄えのする図を作る必要はありません。全ての人が、わかりやすい記号で、簡便に表記できればいいのです。このために作られたルールが、Unified Modeling Language (UML)というものです。UMLを書くのには、色々なツールがありますが、ここでは、Astah* Communityというツールをベースに話していきます。

[Astah* Community スタートガイド] [Astah* Community UML初学者向けチュートリアル]

UMLは、『ふるまい図 (Behavior Diagram)』と『構造図 (Structure Diagram)』と呼ばれる2つの形の図を持ちます。ふるまい図は、要求や要件、そのソフトウエアの動作がどうなるのかを定義するための図です。構造図は、そのソフトウエアの個々のパーツが、どのような関係で動作し、また、グループ化されるかを表します。要件定義では、基本的にふるまい図の方を用いて考えて行きます。

ふるまい図の中の1つに、ユースケース図というものがあります。ユースケース図は、登場する人物と、操作する画面やソフトウエアパーツが、どのような相関関係で操作されるのかを定義するものです。

詳細な書き方は、[IT専科: ユースケース図] を参考にしてください。

左図は、簡単なユースケースの一例です。ユーザーは基本的に1人で、共有するものはないのですが、一部、ユーザーの親に、メールによる通知で情報を共有するので、そのためのソフトウエアパーツを介して、ユーザーの親にデータを届けます。

また、ユーザーが見る画面や、入力する画面などが、ユーザーに近いところにあり、どのように操作があるのかをこの図では示しています。

これらのソフトウエアパーツは、機能要件で示されたものが入ります。

Astah* を用いた場合のユースケース図の書き方は、左のムービーの通りになります。（by Lynda.com 日本版 ）

Astah* Communityを用いると、WindowsでもMacでも、簡単にUMLを作図することができます。また、他の図に、一度書いた図を再利用することができるので、便利です。

使われる流れからの要件の定義: アクティビティ図

アクティビティ図は、ふるまい図の一種で、ユーザーの入力や、他からのデータの入力から、どのような動作をして、出力まで向かうのかを定義するものです。ユースケースが、ユーザーとソフトウエアパーツ、またはソフトウエアパーツ相互間の関係だけを見るものに対して、アクティビティ図は、そこからどのような流れでそれらが扱われ、入力から出力まで行くのかを見るものとなります。

左図はアクティビティ図として書いた、ユーザーがアプリを使い始めた時に発生する、初期情報の入力と、その情報を親のメールに通知するという流れです。入力した情報が、正しい条件で入力されているかを判断して、その後に週間目標体重が設定されて、それをユーザーが閲覧でき、また、その週間目標が親に通知される、という流れを表しています。

アクティビティ図は、1つのアプリケーション中に基本的に複数の図が含まれます。左図も、アクティビティ図として書いた、毎日の入力に対する動作の定義です。

入力されたデータは、点数化されてデータベースへ保存されますが、一方で、先に一度入力したデータが存在している場合は、格納ではなく更新しなければいけません。その流れを追加しています。

アクティビティ図のパーツの定義については、[IT専科: アクティビティ図] を参照してください。

Astah* を用いた場合のアクティビティ図の書き方は、左のムービーの通りとなります（by astah*5分レッスン ）

アクティビティ図は、動作に対して規定しますので、アプリケーションを実際に動作させると、どのように動けばいいだろうかなど、想像を膨らませながら、順次書いていくと、まとまります。

手で書く場合は非常に大変ですが、ツールを用いると、簡単に作成できます。

データのやり取りからの要件の定義: シーケンス図

続いて、データのやり取りから要件を定義する『シーケンス図』について説明します。特にツールは、何らかの情報をデータとして受け取って、そのデータのやり取りと計算を経て、役に立つ情報として表示することがほとんどです。シーケンス図もふるまい図のうちの1つですが、ユースケース図、アクティビティ図よりも、より深い考察となります。

注目したいのは、ユースケース図やアクティビティ図は、単純な矢印で流れを追った『チャート』と言うものでしたが、シーケンス図は、時間の流れを定義して、どこにどのようなデータが流れていくか？を縦方向に表した図となります。このため、実際にアプリケーションを動かすことを想像しながら、その中身の流れを書いていくことになります。

左の図は、ログの入力から、データベースへの格納、また、そこから体重の折れ線出力までのデータとプログラムの流れについて表現したシーケンス図です。

シーケンス図は、ソフトウエアパーツがラベル付きで縦に直線が引かれます。スタートとなる場所からデータを送られると、そのタイミングからソフトウエアパーツが動き出します。動き出している間にデータが戻ってくれば、その次の動作に行きます。

このシーケンス図は、簡単に作成していますので、実際にはもっと多く書き込まないといけないものです。

シーケンス図のパーツの定義は [IT専科: シーケンス図] を参考にしてください。

Astah* を用いた場合のシーケンス図の書き方は、左のムービーの通りとなります。（by ChangeVision Astah）

シーケンス図は、パーツ間のデータの動きに対して規定しますので、データがアプリケーションに入った時に、どのパーツにどのようにデータを動かせば、アプリケーションが実際に動くのだろうかと、考えながら、順次書いていくと、まとまります。

これも、手で書く場合は非常に大変です。是非、ツールを用いて、簡単に作成してください。

Google Sites

Report abuse