問31
頻出度★★☆
システムが実現すべき応答時間などのシステムの品質を明確にする工程として, 適切なものはどれか。
平成25年度 秋期 ITパスポート試験 問31
ストラテジ系システム企画 › 要件定義
这道题的解析和你的作答记录。
解説
問 31
错误ア
系统测试是在接近生产的环境中，确认所开发的系统整体是否满足需求定义中所确定内容的工序。关于响应时间，也会通过性能测试来测定并验证是否满足作为需求所确定的目标值，但那是把「已经明确的质量水平」当作判定基准来使用的立场，并不是在这里决定质量水平本身。这是把明确需求的工序（入口）与确认是否满足需求的工序（出口）弄混了的选项。
- イ
正解 正确答案是イ「系统需求定义」。系统开发按照 企划 → 需求定义 → 设计 → 编程 → 测试 → 导入·运行 的顺序推进，决定「做什么」的是需求定义，决定「怎么做」的是设计及其之后的工序。需求定义所处理的需求大致分为两类：一类是规定系统所提供的功能本身（处理哪些处理、哪些数据）的功能性需求，另一类是规定这些功能要以何种水平实现的非功能性需求。题目中的响应时间正是后者即非功能性需求的典型例子，此外还包括处理件数等性能、运行率与故障恢复时间等可用性、安全性、扩展性、运行与维护的便利性等。这些对系统所要求的质量水平，必须在开发入口的系统需求定义工序中，由使用者·发包方与开发方达成一致并明确下来。如果不在这里以数值目标的形式形成文档，后续工序的设计就无法确保所需的性能，测试时也无法拥有合格与否的判断基准，从而成为返工的原因。因此，明确响应时间等系统质量的工序就是系统需求定义。
错误ウ
软件详细设计是承接需求定义和系统方式设计所确定的内容，把程序的内部结构（模块划分、处理步骤、数据结构、输入输出的细节等）具体化到可以编程的粒度的工序。虽然为了达成响应时间的目标，可能会在算法和数据的组织方式上下功夫，但那是对实现既定目标值的手段的研究，而不是确定目标值本身的工序。需求作为详细设计的输入已经确定，这是前提。
错误エ
编程是根据详细设计的内容用程序设计语言编写代码，并通过单元测试确认其运行情况的工序。这里进行的是按照设计做出能够运行之物的作业，而不是决定对系统所要求的质量水平的场合。它是距离需求定义最远的实现阶段的工序，如果到了这个阶段才开始决定响应时间的目标，就会在设计不满足需求的状态下推进实现，造成很大的返工。
ここがポイント
- 需求定义是决定「做什么」的工序，需求分为功能性需求和非功能性需求。功能性需求是系统应具备的功能·处理·数据的内容，非功能性需求是响应时间和处理件数等性能、运行率等可用性、安全性、扩展性、运行与维护性等质量方面的要求，两者都要在系统需求定义中明确，并尽可能以数值达成一致。
- 系统开发的工序按 企划 → 需求定义（业务需求定义·系统需求定义）→ 系统方式设计·软件设计（概要设计·详细设计）→ 编程 → 测试（单元·集成·系统·运行）→ 导入·运行 的顺序推进。要掌握各自角色的差异：需求定义是开发入口处「决定」的工序，测试是出口处「确认」是否满足需求的工序，设计和编程则处于两者之间，是把实现需求的手段具体化的工序。
用語