問2
頻出度★★☆
証券業を営む A 社は, システムベンダの B 社に株式注文システム構築プロジェクトを委託している。当該プロジェクトの運用テストにおいて, A 社が定めている “株式注文時の責任者承認における例外ルール” を B 社が把握できていなかったことに起因する不良を発見した。ルールを明らかにするのはどの段階で行うべきであったか。
平成25年度 秋期 ITパスポート試験 問2
ストラテジ系システム企画 › 要件定義
这道题的解析和你的作答记录。
解説
問 2
- ア
正解 正确答案是 ア「业务需求定义」。题目中成为焦点的「股票下单时责任人审批的例外规则」，是 A 公司作为自身业务所制定的运营层面的规定，属于在决定系统要实现什么之前的「业务应有形态」这一层面的信息。按共通框架的流程，需求定义是按 (1) 业务需求定义 →(2) 系统需求定义 →(3) 软件需求定义 的顺序，从上游向下游逐步具体化的。业务的规则、体制、例外处理这类内容，应当由用户方（A 公司）在最上游的业务需求定义中明确提出，并与供应商（B 公司）达成一致；正因为在这一环节被遗漏，才没有反映到下游的系统需求和软件需求中，最终在最后阶段的运行测试中以缺陷的形式暴露出来。因此，本应明确该例外规则的阶段就是业务需求定义。
错误イ
系统测试需求定义是决定如何确认已完成的系统是否按需求运行的工序，即确定测试范围、测试用例和合格标准。测试需求是以业务需求和系统需求为输入而编制的，因此如果业务规则本身没有被明确，测试需求中也不会体现出来。到这个阶段才察觉已经为时过晚，它并不是「明确」规则的场合。
错误ウ
系统需求定义是为了实现已确定的业务需求，决定系统整体应具备的功能、性能、接口等内容的工序。它是在前提条件——业务规则——被给定之后才能成立的下游工序，并不是挖掘业务方例外规则本身的场合。如果这类规则到这里才第一次出现，那就说明在上游的业务需求定义中存在达成一致的遗漏。
错误エ
软件需求定义是把系统需求进一步分配到各个软件上，将画面、报表、处理内容、数据结构等细化的工序，是需求定义之中最下游的环节。此时的前提是业务规则已经确定，因此把它当作重新明确审批例外规则这一业务层面规定的阶段是不合适的。
ここがポイント
- 需求定义按「业务需求定义 → 系统需求定义 → 软件需求定义」的顺序，从上游向下游逐步具体化。业务的规则、体制、例外处理应由用户方在最上游的业务需求定义中明确提出，并与供应商达成一致。
- 业务需求定义由发包方（用户部门）主导承担。这里的遗漏会波及到下游所有工序，直到运行测试等末期才作为缺陷被发现，因此返工成本最大。
用語