問26
頻出度★★☆
ソフトウェアライフサイクルを, 企画, 要件定義, 開発, 運用のプロセスに分けたとき, 要件定義プロセスの段階で確認又は検証するものはどれか。
平成26年度 春期 ITパスポート試験 問26
ストラテジ系システム企画 › 要件定義
This question's explanation and your answers so far.
解説
問 26
Incorrectア
“Consistency and traceability between system requirements and software requirements” is a check made inside the development process. In development, the system requirements are defined first, and then they are allocated to hardware, software, manual operations, and so on in order to define the software requirements. At that point you verify whether the higher-level system requirements are reflected in the lower-level software requirements without omission, and whether you can trace which software requirement corresponds to which system requirement. At the requirements definition stage, neither the system requirements nor the software requirements have been created yet, so there is nothing to check.
Incorrectイ
“Feasibility of the software design with respect to the software requirements” is a check made at the software design stage (architectural design and detailed design) of the development process. It is the work of verifying, against software requirements that have already been fixed, whether the design can really be realized and whether it can meet the performance targets and constraints. That comes much later than the requirements definition process, which fixes the business requirements.
- ウ
正解 When the software life cycle is laid out as “planning → requirements definition → development → operation,” the requirements definition process is the stage where you take the direction for system development decided in the planning process, draw out what users and customers want to achieve in their business, organize it as “business requirements,” and reach agreement among the people involved. At this stage the inside of the system (system requirements, software requirements, and design) has not been decided yet, and what should be confirmed or verified is validity (validation): whether the business requirements you have defined really match the needs and wishes of users or customers. If the requirements are misunderstood here, no matter how accurately the later stages build the system, the result is a system that is “not what we wanted,” and the cost of rework is the largest. Therefore, the correct answer for what is confirmed or verified during the requirements definition process is “ウ Validity of the business requirements as seen from the needs and wishes of users or customers.”
Incorrectエ
“Feasibility of the software item that satisfies the allocated requirements” is also something checked in the development process. The very phrase “allocated requirements” shows that the system requirements have already been distributed to components such as software, and the check is whether, with that allocation, the software item (the unit of software to be built) can be realized. This is not what the requirements definition process checks, which is matching the wishes of users and customers against the business requirements.
ここがポイント
- In the software life cycle of the Common Frame, the order is: planning process (system concept and plan) → requirements definition process (defining and agreeing on business requirements) → development process (system requirements definition, software requirements definition, design, implementation, testing) → operation process. What is checked in which process can be judged from which deliverables exist at that point in time.
- What the requirements definition process confirms and verifies is validation: whether the business requirements are valid in light of the needs and wishes of users or customers. Verification of consistency, traceability, or feasibility that targets system requirements, software requirements, or design all belongs to the development process.
用語