アプリ開発、システム開発、WEBサイトでもそうですが
まず、最初に行うのが要件定義です。
要件定義とは何かについてはこちらをご覧ください。
ご参考：要件定義とは
この要件定義という工程。何度もその重要性は記してまいりました。
これをお読みいただいているみなさまなら、要件定義は大切なことだから、しっかりと行う必要がある！と思って頂いているはずです。
要件定義は、「要件」を定義するのですが、はて、それは具体的にどうやって定義するのだろう？
一歩理解が進むと、そのような疑問も浮かんでくるかと思います。
出来上がったアプリ・システムを見ても、これらが一番先にどのように要件を定義したのか？分かりませんよね。
実は、この要件定義のやり方自体、開発会社のノウハウの塊であって、成果物となる「要件定義書」は各社違いがでてきます。
定義する要件 ところで非機能要件ってなに？
要件定義は「機能要件」と「非機能要件」に大別されます。
ユーザーが理解しやすいのは「機能要件」です。
機能要件は、その名の通り、この機能はこんな役割、こんなことをしたいということを定義するもの。
例えば、メッセージが届いたらプッシュ通知が来る。こんな機能が必要ということです。
では、非機能要件とは何か。
「非」が付いているくらいですから、どうやら機能そのものではないというのは想像がつくかと思います。
直接的な機能ではないけれど、アプリ・システムを運用するにあたって必要な事柄。それが非機能要件だと理解してください。
非機能要件の例
非機能要件については、このようなものが挙げられます
性能要件
運用要件
セキュリティ要件
データの移行
障害対策
細かな話しは、今回割愛しますが、内容はそれぞれの言葉どおりです。
全ての登録処理は、登録ボタンをタップしてから１秒以内にできなければならない、万が一不正アクセスされても情報を保護できるようにしなければならない、障害が発生した場合、３０分以内に復旧させる必要がある。２４時間３６５日休みなく稼働すること。
ざっくり、単純に言うと上記のような内容ですが、この例は実際は現実的ではありません。
本気でこの要件を実現するためには、多額の開発、運用コストがかかるからです。
分かりやすい例でいうと、障害が発生して３０分以内に復旧させるということは、復旧させるためのエンジニアを２４時間３６５日配置しておかなければならないということ。その費用はご想像どおりです。
あらゆる処理が素早く行われ、不正アクセスにも強い耐性があり、障害が発生せず、発生しても速やかに復旧しかつずっと動き続けるシステム。
理想的ではありますが、世の中の著名なシステム（あのグーグルですら）でもこうはいきませんので、かけられる費用との見合いで開発会社と相談し、現実的な範囲を決める必要があります。
非機能要件の定義はよくわからなさそう。なのですが、全く話題に上げないまま進めると、とんでもないことになる可能性を含んでいるのもまた非機能要件なので、妥協があるにしても何等か定義はしておきましょう。
要件定義はどこまで定義するものなのか
さて、では機能要件にスポットを当てるとして、それはどこまで定義すればいいのでしょう。
例えば、これから作るアプリでは「顧客検索機能」が必要だとします。その場合の要件はどうなるでしょう？
=（１）===============================================================
顧客検索ができなければならない
=（２）===============================================================
・顧客検索ができなければならない
・検索条件は氏名、都道府県、メールアドレスとする
=（３）===============================================================
・顧客検索ができなければならない
・検索条件は氏名、都道府県、メールアドレスとする
・条件を複数入力した場合は、AND条件とする
・検索結果は一覧表示され、検索した条件および氏名、読み仮名、電話番号を表示、氏名をタップすると顧客の詳細情報を表示する
・検索画面イメージは図１、検索結果は図２の通りとする
===================================================================
さて、（１）～（３）のどれが、ユーザーと開発会社にとって、できあがりイメージの相違がないかお分かりでしょう。
この例はシンプルな機能ですから、（１）であっても出来上がった結果は大差ないかもしれません。
しかし、これが業務アプリならば、業務上必要な検索結果というものがあります。その場合、具体的に定義しないと開発会社がイメージ通りに作ってくれる可能性は低くなります。
また、要件定義は（１）の範囲でよい。設計フェーズで具体的に定義するから。
という考え方もあります。開発会社によっては、このような方針である場合もあります。
（ここまで極端ではなくとも、昔当社もそれに近い考えの時がありました）
しかし、完成したアプリ・システムが依頼通りになっているかを検証する資料であり、最終的な見積もりの根拠になるのは「要件定義書」です。
そうである以上、要件定義では可能な限り細かな点に踏み込んで、ユーザーと開発会社の間で作るもののイメージが一になるよう努力すべきでしょう。
スマホアプリを使った業務システム構築のことなら
株式会社クラボードへお気軽にご相談ください