問43
頻出度★★☆
ソフトウェア開発におけるシステム要件定義において, 業務上の要件が満たされていることを確認するのに適切な者は誰か。
平成24年度 春期 ITパスポート試験 問43
ストラテジ系システム企画 › 要件定義
这道题的解析和你的作答记录。
解説
問 43
错误ア
运维部门的操作员是在系统投入运行之后，负责作业执行、监控、备份等运维操作步骤的角色。对于批处理的执行时间段、运维负荷之类的运维需求，他们能够提出有益的意见，但并不处于判断业务本身的目的、以及该业务能否按需求得以开展的立场。而且他们也没有代表部门批准需求定义书的权限，因此作为确认业务上的要求是否得到满足的人并不合适。
错误イ
开发部门的程序员属于承接已定义好的需求、进行设计与实现的制造方。他们能够判断技术上的可行性和工时是否合理，但业务需求是否正确、有无遗漏或多余，应由使用部门来决定，不是开发方可以代为判断的事情。另外，由自己来判定自己所要制造的对象是否满足需求，缺乏客观性，还有把对需求的主观臆断或理解偏差原封不动带进来的危险。
错误ウ
审计部门的系统审计师的角色，是站在独立于开发和运维当事方的立场上，评价控制与流程是否得到恰当的建立和执行，并提出建议和劝告。他们可能会检查需求定义的推进方式和达成共识的手续是否妥当，但如果深入到业务需求的具体内容之中、以当事方的身份确认并批准「这样就可以」，就会损害自身的独立性。因此作为确认业务上的要求已得到满足的人并不合适。
- エ
正解 正确答案是 エ「使用部门的部门负责人」。系统需求定义是这样一道工序：以使用部门所面临的业务上的要求(业务需求)为出发点，定义为实现这些要求而系统应具备的功能、性能和约束，并由发包方与开发方达成共识。这里需要确认的是「按照这些系统需求做出来，自己的业务能否运转、业务上的目的能否达成」这一点，而能够作出这一判断的，是最了解业务内容、处理步骤和例外情况的当事方，也就是实际使用该系统的使用部门。此外，需求定义的交付物是后续设计、开发工序的前提，一旦确定后再变更就会招致返工和成本增加，因此确认者不能只是「熟悉情况的人」，而必须是能够代表部门评审内容、并负责任地批准和确认的、拥有相应权限的人。使用部门的部门负责人同时满足这两个条件(业务知识与批准权限)，作为需求定义书的评审与批准者最为合适。在共通框架等标准中也认为，需求定义由使用方(取得方)负责进行，并以利益相关方的共识来确定，这一点同样印证了上述思路。
ここがポイント
- 系统需求定义中的角色分工 —— 提出业务需求、确认其得到满足并对需求定义书作出批准和确认，是使用部门(发包方)的责任；开发部门负责实现，运维部门负责投入运行之后的运维，审计部门负责以独立立场进行评价，各自的角色互不相同。
- 确认者必须具备的两个条件 —— 既熟知业务的内容和目的，又拥有代表部门就需求达成共识并予以批准的权限，同时满足这两点的人才胜任；从这个角度出发，选出的就是使用部门的部门负责人。
用語