問2
頻出度★★☆
証券業を営む A 社は, システムベンダの B 社に株式注文システム構築プロジェクトを委託している。当該プロジェクトの運用テストにおいて, A 社が定めている “株式注文時の責任者承認における例外ルール” を B 社が把握できていなかったことに起因する不良を発見した。ルールを明らかにするのはどの段階で行うべきであったか。
平成25年度 秋期 ITパスポート試験 問2
ストラテジ系システム企画 › 要件定義
This question's explanation and your answers so far.
解説
問 2
- ア
正解 The correct answer is ア, “Business requirements definition.” The “exception rule for manager approval at the time of stock orders” at issue here is an operational rule that Company A has established for its own business, and it belongs to the level of “how the business ought to work” — information that comes before deciding what to implement in the system. In the flow of the Common Frame, requirements definition is made concrete from upstream to downstream in the order (1) business requirements definition → (2) system requirements definition → (3) software requirements definition. Business rules, organizational structures, and exception handling must be stated explicitly by the user side (Company A) in the most upstream business requirements definition and agreed on with the vendor (Company B). Because this was missed there, it was never reflected in the downstream system requirements or software requirements either, and it finally surfaced as a defect in the operational test at the very end. Therefore, the stage at which this exception rule should have been clarified is the business requirements definition.
Incorrectイ
System test requirements definition is the process of deciding how to confirm that the completed system works as required — the test scope, test cases, and pass/fail criteria. Test requirements are created using the business requirements and system requirements as input, so if a business rule has not been made clear in the first place, it will not appear in the test requirements either. Noticing it at this stage is already too late, and this is not the place where the rule is “clarified.”
Incorrectウ
System requirements definition is the process of deciding the functions, performance, interfaces, and so on that the system as a whole must have in order to realize the business requirements that have already been fixed. It is a downstream process that only works once the underlying business rules have been given, and it is not the place to dig up the business side’s exception rules themselves. If such a rule comes up here for the first time, it means agreement was missed in the upstream business requirements definition.
Incorrectエ
Software requirements definition is the process of further allocating the system requirements to individual pieces of software and working out details such as screens, reports, processing content, and data structures; it is the most downstream part of requirements definition. It assumes that the business rules have already been fixed by this point, so it is not appropriate as the stage for newly clarifying a business rule such as an exception rule for approval.
ここがポイント
- Requirements definition becomes concrete from upstream to downstream in the order “business requirements definition → system requirements definition → software requirements definition.” Business rules, organizational structures, and exception handling should be stated explicitly by the user side in the most upstream business requirements definition and agreed on with the vendor.
- Business requirements definition is led by the client side (the user department). An omission here propagates to every downstream process and is only discovered as a defect late in the project, such as during the operational test, which makes the cost of rework the largest.
用語