マネジメント系 › システム開発技術› システム開発技術› 単元 1 / 5要件定義と設計 頻出 約 33 分 5 用語 過去問 19 題
AI 先生に聞く
この単元の目標 機能要件 と非機能要件 を見分け、どちらもシステム要件定義の段階で明確にするものだと説明できる。品質特性 の各特性が何を見る観点かを知り、具体的な記述がどの特性に当たるかを判断できる。要件定義から設計を経てプログラミングへ進む流れの中で、機能設計 と詳細設計 がそれぞれ何を決めるかを説明できる。 用語総表（5 語） 用語 機能要件 は、システムが何をするか 、つまり業務のためにどんな処理や機能を提供するかを定めた要件である。
要件定義では、業務の流れや使い方を分析し、システムに任せる処理を洗い出す。例えば図書の貸出システムなら「会員番号で貸出を記録する」「返却期限を過ぎた本を一覧にする」が機能要件に当たる。工程を細かく分ける呼び方には、システム全体の要件を決めるシステム要件定義 や、その中のソフトウェアについて決めるソフトウェア要件定義 がある。
たとえ レストランのメニューに並ぶ料理の一覧のようなもの。この店で何を出せるかを決めたもので、作り方はまだ書かれていない。
出題のポイント
出題 システム要件定義では、システムが持つべき機能と性能 を明確にし、システム化する対象範囲 もこの段階で決める。出題 ソフトウェア要件定義では、ソフトウェアが扱うデータの項目や定義 を明確にする。処理の動作ロジックを考えてコードを書くのは、後の設計・プログラミングの工程である。出題 発注側は納品物に仕様書どおりの機能が備わっているかを、利用部門はシステムが業務の要件 を満たすかを確かめる。個々のプログラムが設計どおりに動くかの確認は開発側の役割である。この用語の過去問 3 題 機能要件 →
非機能要件 は、応答の速さ・止まりにくさ・安全性・運用のしやすさなど、機能をどの水準・条件で 提供するかを定めた要件である。
非機能要件も機能要件と同じく要件定義の段階で目標を決める。目標はできるだけ数値など確かめられる形にしておくと、後で達成できたかどうかを判定しやすい。
たとえ 注文を受けてから 10 分以内に料理を出す、といった店の約束にあたる。料理の種類ではなく、出し方の水準を決めている。
覚え方 「非」は機能を否定するのではなく「機能以外」の条件を指す。機能がそろったうえに付く条件と読む。
出題のポイント
出題 応答時間の目標値のような性能の目標は、システム要件定義 で決める。設計の段階まで先送りするものではない。出題 開発したシステム全体を確かめるシステムテスト では、機能が正しく動くかに加えて、性能などの非機能要件 を満たしているかも確かめる。混同注意 機能要件は業務のための処理そのもの を定め、非機能要件はその処理に求める性能・信頼性・安全性・運用などの水準や条件 を定める。この用語の過去問 2 題 非機能要件 →
品質特性 は、ソフトウェアの品質を「使いやすいか」「故障しにくいか」などの観点 ごとに分類したものである。
規格 JIS X 25010:2013 では 8 つの特性に分け、それより前の規格では 6 つの特性に分けていた。前の規格の機能性は、JIS X 25010 の機能適合性にほぼ当たる。漠然とした「品質が良い」を観点に分けることで、要件を定めるときに目標を決めやすくなり、出来上がりも観点ごとに評価できる。
たとえ 車を燃費、乗り心地、故障の少なさ、整備のしやすさといった項目ごとに採点する評価表のようなもの。
出題のポイント
出題 使用性 は、利用者が覚えやすく、少ない手間で使いこなせるかという特性である。利用者と、画面などシステムの操作部分との接点に関わる。出題 機能性 は仕様に沿って正しい結果を出す性質、信頼性 は誤った入力や故障があっても正常な動作を保つ性質である。この用語の過去問 3 題 品質特性 →
機能設計 は、要件定義の結果をもとに、画面や帳票など利用者から見える仕様 を決める設計工程で、外部設計とも呼ばれる。
機能設計では、利用者が操作する画面の項目や配置、出力する帳票の様式、利用者の操作の流れなどを決める。ここで決めた仕様は利用者が見て確かめられるので、要望とのずれをこの段階で見つけやすい。
たとえ 家づくりで、施主の要望をもとに間取り図や外観図を描く段階。住む人が見て、使い勝手を確かめられる図面にあたる。
出題のポイント
出題 画面や帳票に載せる項目と、その配置や様式を決めるのは、外部設計 (機能設計) である。出題 システム方式設計 は細かく分ける呼び方の工程で、要件をハードウェア・ソフトウェア・手作業に割り振り、機器やネットワークの構成を決める。利用者から見える仕様は決めず、機能設計の別名ではない。この用語の過去問 3 題 機能設計 →
詳細設計 は、それまでの設計で決めた仕様を、プログラムを書ける細かさの内部の仕様 にまで具体化する設計工程である。
工程を細かく分ける呼び方では、ソフトウェア詳細設計 の段階で、コーディングするプログラム 1 本ごとに処理の手順やデータの扱いを決める。決めた内容は設計書にまとめ、プログラミングの拠り所にする。
たとえ 間取り図をもとに、柱の位置や配線・配管の通り道まで描き込んだ施工図。職人がそのまま作業に入れる細かさにする。
出題のポイント
出題 ソフトウェア詳細設計で初めて決めるのは、1 本ずつのプログラムの仕様である。その設計書に基づいて、次の工程でプログラマがプログラミングを行う。出題 プログラムが条件ごとにどう分岐して処理するかを考え、流れ図 で書き表す作業は、ソフトウェア詳細設計の段階で行う。混同注意 機能設計は画面や帳票など利用者から見える外側を、詳細設計はプログラムの処理手順など開発者が作る内側 を決める。この用語の過去問 3 題 詳細設計 →
要点 開発は、要件定義で「何を作るか」を決め、設計で「どう作るか」を段階的に細かくし、プログラミングへ進む。 品質特性は、記述が表す性質 (使いやすい、故障に強い、別の環境で動く など) から、どの特性に当たるかを見分ける。 工程の呼び方には、本単元の図のように要件定義、機能設計 (外部設計)、詳細設計と粗く分けるものと、システム要件定義やシステム方式設計のように細かく分けるものがある。両者の区切りは一対一には対応しないので、工程の順序はどちらか一方の呼び方の中で考える。 この分野の過去問をすべて見る →
読了