問43
頻出度★★☆
システム要件定義において, システム要件を評価する基準として, 適切なものはどれか。
平成26年度 春期 ITパスポート試験 問43
ストラテジ系システム企画 › 要件定義
这道题的解析和你的作答记录。
解説
問 43
错误ア
系统集成测试是把经过需求定义、设计、编程之后做出来的各个模块组合起来，确认系统整体能否正确运行的下游工序。在进行需求定义的时间点上，它还没有实施，结果也并不存在，所以不可能成为评估需求的基准。两者的关系其实正好相反：先有系统需求，测试一方是在之后来确认系统是否满足这些需求。
- イ
正解 正确答案是 イ「与系统委托方（发包方）需求的一致性」。系统需求定义位于系统开发生命周期的最上游，其工作是把委托方、使用部门等利益相关方在业务上想要实现的内容挖掘出来，整理成系统应具备的功能、性能和约束条件，最后与委托方达成共识。这里形成的需求会成为之后的设计、编程、测试的全部起点，因此能够衡量需求本身好坏的尺度，不是「后续工序的交付物」，而只能是「作为这些需求源头的委托方的真实需要」。如果带着与委托方真正需要的东西相互矛盾的需求继续往下推进，那么设计、程序、测试即使在技术上都做得正确，最终建成的系统也无法用于实际业务，造成最严重的返工。而且需求上的错误越流到下游工序，修正成本就越大，因此在需求定义阶段就与委托方核对内容、确认有无遗漏或理解偏差并达成共识非常重要。所以，作为评估系统需求的基准，恰当的是与委托方需求的一致性，イ 正确。
错误ウ
设计方法是否恰当，是在决定「如何实现」需求的系统设计工序中的评价视角。需求定义所决定的是「实现什么」，它并不是规定实现方法的阶段。而且无论设计方法多么优秀，只要原本的需求与委托方的需要相互矛盾就毫无意义，因此把它作为评估需求本身的基准是不恰当的。
错误エ
测试用例的覆盖性是衡量测试计划和测试设计质量的视角，表示对应当测试的条件梳理得有多全面、有无遗漏。它评价的对象是测试的充分性，而不是需求的合理性。此外，测试用例是依据已经确定的需求来编写的，所以在需求定义阶段无法把它的覆盖性当作判断需求的基准。
ここがポイント
- 系统需求定义是决定「实现什么」的最上游工序，其目标是挖掘委托方、使用部门等利益相关方的需要并整理成需求，再与委托方达成共识（需求的达成共识）。衡量需求是否恰当的基准，就是与委托方需求的一致性。
- 要区分不同工序的评价视角：需求定义＝与需要的一致性，设计＝实现方法和设计方法的恰当性，测试＝测试用例的覆盖性和测试结果。上游的错误越流到下游，修正成本越大，因此在需求定义阶段与委托方进行确认并达成共识就显得很重要。
用語