問8
頻出度★★☆
システム開発における業務要件を定義する目的として, 適切なものはどれか。
平成24年度 春期 ITパスポート試験 問8
ストラテジ系システム企画 › 要件定義
This question's explanation and your answers so far.
解説
問 8
Incorrectア
“To make effective use of the enterprise's management resources and manage them in an integrated way” describes the concept of ERP (Enterprise Resource Planning) and the purpose of the ERP packages that implement it. ERP gathers information that tends to be fragmented by function, such as accounting, human resources, production, sales, and inventory, into a single integrated database, and aims to manage the management resources of people, goods, money, and information from a company-wide optimal viewpoint. This explains a management framework and the nature of a product being introduced; it is not the purpose of the work of eliciting requirements and agreeing on them with stakeholders in an individual system development project.
Incorrectイ
“To fundamentally review and rebuild business flows, the organization, and systems” describes BPR (Business Process Reengineering). Rather than partially improving existing work procedures, BPR means wiping the slate clean and redesigning the flow of work and the shape of the organization themselves, a management approach that aims at dramatic gains in efficiency and in customer value. Business requirements definition also depicts what the new operations will look like, which is a point in common, but its purpose is ultimately to determine the scope and functions to be implemented as a system and to obtain the stakeholders' agreement; radically rebuilding the organization and the business itself is not its goal.
Incorrectウ
“To create policies and an implementation plan for IT adoption in order to achieve management goals” is the purpose of the planning process that comes before requirements definition, that is, of formulating the information systems strategy (IT strategy) and of the system concept and system plan. At that stage, starting from the corporate strategy and management goals, the overall direction is decided: which business areas will be computerized and in what order, how much will be invested, what organizational structure will be used, and what the schedule will be. Business requirements definition takes that direction and turns it into concrete scope and functions for each individual system, with agreement among the parties. Both belong to the upstream stages, but they are different steps within them. The key point is not to confuse creating policies and plans with making things concrete and building agreement.
- エ
正解 The correct answer is エ, “To make the scope and functions of system implementation concrete and reach agreement among stakeholders.” Business requirements definition is the central task of the requirements definition process, which sits upstream in system development, and it fulfills two roles at the same time. The first is making things concrete. The vision that was still rough at the system planning stage is drilled down to this level: how the new business operations will be carried out step by step, what information is entered and what is produced as output, and what business constraints exist (laws and regulations, deadlines, processing volumes, the organizations and roles involved). On that basis, the target scope of exactly how much will be realized by the system, together with the required functions and performance, is put into writing. The second role is reaching agreement. What is decided here concerns every stakeholder, and they hold different positions: executives, the user departments that actually perform the work, the information systems department, and the side responsible for development. So, after confirming that all parties share the same understanding, the content is compiled into a requirements definition document and formally approved. This agreed document becomes the premise for the later design, development, and testing, and it also becomes the criterion for judging whether the finished system can be accepted. Conversely, if you move ahead while the scope and functions are still vague, or while some parties still understand things differently, a gap in understanding along the lines of “this is not what we asked for” surfaces at the end of development, causing major rework and cost overruns. That is exactly why the purpose of business requirements definition consists of two inseparable halves, making the scope and functions concrete and reaching agreement on them among stakeholders, so エ is correct.
ここがポイント
- The purpose of business requirements definition — after clarifying how the new operations will be carried out, make the target scope of system implementation and the required functions concrete, reach agreement among stakeholders such as executives, user departments, and the development side, and compile it all into a requirements definition document. Because this agreed document is the premise for design, development, and testing and also the criterion for acceptance judgment, proceeding while things remain vague causes major rework late in the project.
- The order of the upstream stages and telling confusable terms apart — remember the sequence: corporate strategy → information systems strategy, system concept, and system plan (the planning process, choice ウ) → the requirements definition process (business requirements definition, choice エ) → the development process. Along with that, separate the terms by purpose: integrated management of management resources is ERP (choice ア), and radically rebuilding business flows and the organization is BPR (choice イ).
用語