問23
頻出度★★☆
ソフトウェアライフサイクルを, 企画, 要件定義, 開発, 運用のプロセスに区分したとき, 要件定義プロセスで明確にする項目はどれか。
平成25年度 春期 ITパスポート試験 問23
ストラテジ系システム企画 › 要件定義
This question's explanation and your answers so far.
解説
問 23
Incorrectア
Clarifying the purpose of developing the system belongs to the planning process, which comes before the requirements definition process. In the planning process, a concept and a plan for building the system are drawn up in the light of management issues and needs, and the purpose of building the system, its scope, its return on investment, the overall schedule, and so on are decided. The requirements definition process starts from the purpose decided there and works out the concrete requests of the stakeholders, so the purpose itself is not an item first decided in requirements definition.
Incorrectイ
Clarifying the function and capability of each software configuration item belongs to the development process (software requirements definition and software architectural design), which comes after the requirements definition process. A configuration item is a unit of division used by the side that implements the system, and it is fixed only once the users' requests have been allocated to technical units. At the stage of the requirements definition process, it has not yet been settled into what parts the product will be divided for implementation, so this item does not become a deliverable of requirements definition.
Incorrectウ
The structure of the database is an internal specification decided in the design steps of the development process (software detailed design and database design). What tables and fields are used to hold the data is a choice of implementation method, whereas what stakeholders ask for goes only as far as business requirements such as what information they want to handle. Deciding even such internal structures in the requirements definition process would fix the means of realization in advance, and that departs from the original purpose of clarifying the requirements.
- エ
正解 The correct answer is エ, the needs and requests of stakeholders. In the Common Frame, the software lifecycle is divided in the order planning → requirements definition → development → operation. Of these, the requirements definition process takes over the aim of building the system that was set in the planning process, and identifies without omission what the stakeholders involved in that system (stakeholders ＝ management, users in the business departments, operations staff, business partners, and so on) need and what they want. It organizes these into business requirements and obtains agreement among the parties concerned. In other words, the role of the requirements definition process is not to settle how to build the system but to settle what is necessary for the users, so the item to be clarified is the needs and requests of stakeholders. The requirements agreed on here are then made concrete as system requirements and software requirements in the development process that follows.
ここがポイント
- In the Common Frame, the software lifecycle proceeds in the order planning → requirements definition → development → operation (and maintenance). The planning process covers why the system is built (management needs, and the purpose, concept, and plan for building the system); the requirements definition process covers what is necessary for the users (identifying the needs and requests of stakeholders, business requirements definition, and agreement on requirements); the development process covers how it is built (system requirements definition and architectural design, software requirements definition and detailed design, implementation, and testing); and the operation process covers how it keeps being used.
- The core of the requirements definition process is identifying the stakeholders and reaching agreement on the requirements. The requests of parties in different positions — management, the user departments, operations staff, business partners, and so on — must be drawn out without omission, conflicting requests must be adjusted, and the result must be put together into an agreed document. If development is entered while the requirements are still vague, rework in the later steps becomes large, so the key point is to keep the means of realization (configuration items, database structure, and the like) out of it and to clarify only what is necessary.
用語