pulpul 日本の試験

基本情報技術者 概念書 · システム開発技術

要件定義と分析の基礎

要点と定義

要件定義は、利害関係者のニーズや制約を整理し、システムやソフトウェアが満たすべきことを明確にする作業です。利用者、運用担当者、取得者、供給者などが認識をそろえ、後工程で設計・実装・確認できる形にします。要件定義プロセスでは、利害関係者とそのニーズ、要望、制約条件を識別します。事業の目的からシステム化方針・実施計画を立てる企画や、定義した要件をどう実現するか決める方式設計とは役割が異なります。

システム要件では、システムの境界、対象業務・部署、機能と能力、入出力、操作、外部とのインタフェース、運用・保守・移行などを定めます。ソフトウェア要件では、そのシステムを構成するソフトウェアに求める機能、能力、インタフェースなどを具体化します。業務モデルや論理データモデルを使い、要件がシステム全体の要件に合うか、実現可能かを評価します。取得者と供給者が共同でレビューし、要件と後続の設計・確認項目をたどれるようにすることも大切です。

機能要件は、システムが何をするか、どの範囲を実現するかを示します。たとえば「注文を登録し、在庫を引き当てる」は機能です。非機能要件は、機能そのもの以外の品質や制約、開発・運用条件を示します。性能、可用性、拡張性、運用性、保守性、移行性のほか、開発基準や技術上の制約も該当します。分類の要点は、機能の内容・範囲を決めているのか、機能の品質や実現・運用上の条件を決めているのかです。

適用条件と例

条件の組合せによって動作や値が変わる業務ルールは、決定表で整理できます。条件を行に、条件の組合せを列に、各組合せで行う処理や結果を別の行に置きます。該当する結果に印を付ければ、条件の抜けや結果の食い違いを見つけやすくなります。たとえば「会員か」「購入額が基準以上か」の二条件で、割引の有無を決める表を作れます。会員で購入額が基準以上なら割引、会員でなく基準以上でも割引なし、といった規則を各組合せに割り当てます。作成時は条件の真偽の組合せを列挙し、各列に対応する業務規則を確認します。組合せが多い場合でも、同じ結果になる列を理由なくまとめず、必要な条件を漏れなく扱います。

業務プロセスをデータの流れに着目して表すときは、データフロー図を使います。プロセスはデータを受け取り、処理して、別のデータを出す活動を表します。たとえば「注文を受け付ける」処理が、注文情報を受け取り、受付済み情報を出力する、と表現できます。データの保管場所、流れ、外部の人やシステムとプロセスを区別すると、業務で何が処理・受け渡し・保管されるかを追いやすくなります。図の記号は意味を表すため、線や矢印を処理そのものと取り違えないようにします。

この節の続き

ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。

アプリでこの節を読む