)と考えた、しょっさんです実際に書いてみると、おおまちがいだったことに気が付きました。原稿書けよ、俺って本気で感じています。要件定義をしていく要求編はまだ続きます。前回では、「想いを言葉にできる」人をアーキテクトとすると定義しました。その想いをどうやって言葉にしていくか。手法とフレームワーク、注意点を確認します。良い要件定義とはまず、そもそもの「要件定義」の目標を定めましょう。アーキテクト育成ハンドブックや、Wikipediaでは、次のように記されています。測できる基準を明確にしてゆきます。その上で設計したアーキテクチャに基づくシステムの要求に対する目標達成の見通しを明確にするのです。その結果は要求者に対して合意形成すると共に、下流のシステム設計者に技術移管と指導することが重要です。「要件定義」は(開発依頼のあったソフトウェアやシステムについて)顧客が望んでいる機能や仕様などについて、その概略をまとめた文章・文書を指すこともある[3]。したことをまとめた文書は通常は「要件定義書」と呼ばれる。Wikipedia重要なポイントは次の二つです。簡単にまとめましたが、いずれも難関です。それでは、これらポイントから「良い」要件定義と評価するための、具体的な内容に落とし込んでいきましょう。機能や仕様をまとめたもの個人的な経験則も踏まえて、次の3つがポイントです。(FR:exception)これらが「網羅」されていることが重要です。UI/UXは重要です。ITアーキテクトからできるべきと考えます。忘れがちな「障害が発生した場合」の処理は、方針が定まっていないと、個々に方向性の異なった異常対処を行うことになりますので、かならず含めましょう。「それって可用性要件では?」としか感じないインフラエンジニアは、「クレジットカード番号の検証が済んで、カード会社への要求もすんで、お客様への請求処理まですすんだけれども、そこで障害が発生してDBに処理状況が保管できなかった」ケースは、どの非機能要求に含めるのか考えてみてください。このフロー自体おかしいので、真似しないでくださいネ。(reliability)これらも「網羅」できていることが、必須条件です。)クワッ!!と思われるかもしれませんが、これが担保できないとなりませんし、担保する方法も無きにしもあらずです。セキュリティなどなどがここに含まれます。2.で示している、ソフトウェア(アプリケーション)の品質的要件です。したがって、何をどこまで実現するかが関わってきます。「制約」とは、今のお客様の力では変更することができないもの、例えば法的効力、予算などです。「非機能要件」とは、お客様が個々で定めることのできる「目標」です。99.9%のシステム稼働率を目標にすれば、夜は止まっていても良いなど、そのシステムの目的によって変わるものです。重要性などにより、データの保全性や、可用性も変わることでしょう。システム稼働要件を100%とすることは実質不可能ですから、落とし所をどこにするかを、納得いく「数値」へ確定することが重要なポイントです。「システムテストしますよー」といったとき、一体何を基準にそれらを評価するのでしょうか。「〜の機能が動くこと」とは何を持って動くことと判断するのでしょう。「それは、すべての機能が正しく動作することです」といった場合「では、1万人が同時にアクセスする可能性があるこのシステムにおいて、それらの機能は、どのように動作することが正常動作でしょうか」という反証に答えるすべがなければなりません。機能テストだけを済ませておいて、実際にサービスインした後、「動かないんだけどー」は、この数値目標がないために起こります。)ニコニコ最後に「実現可能性」が担保できるシステムであることを、よくよく検証してください。́ー`)ノ」ではありません。「役所に問い合わせが必要な処理があり、これは1分間に20回しかコールできない制約がある」のに「役所へ問い合わせる機能は、最大で1分間に100回コールする可能性がある」は相反する要件です。あるのは予算が不足するケースです。́ー`)ノ」で終わりではなくて、システムの概要が見えている、または想定アーキテクチャは記述できているべきです。実現するべきシステムの概算は準備できていて、ホントに予算内に納まりそうかどうかのアセスも必要です。デスマーチの温床となる基本は、スケジュール不足ですが、その要員工数は1日を何時間で作業させるつもりなのか、テストを実施する環境はあるのか、法的にリスクはないのか、お客様の責任者は退職しないか、十分にあんテナを貼る必要があります。良い要件定義を実現するにはこれらを遂行するために必要なことは、システム工学において要求分析として定められています。実際に、この要求分析に従って実現することは、不可能であることは見ていただければ明確です。言え、本来、ITアーキテクトやコンサルタント、ITエンジニアに求められる能力とは、それ相応のものであることは理解しておかねばなりません。言え、何を学んでおくべきか、何を知り得るべきか、については世の中に便利なフレームワークや体系がありますので、これらを利用しない手はありません。技術的知識よりもITアーキテクトは、コミュニケーション能力が重視されます。それらについては、次回以降。これ、完成するのかな。まとめまだ推敲したい段階ですが、FR/NFRともに3:3の項目が出ているので、後はより詳細に書いていくくらいしかなさそうなので、この辺にしました。キャンセル投稿を送信できませんでした。メールアドレスを確認してください。メール送信チェックに失敗しました。このブログではメールでの投稿共有はできません。