問31
頻出度★★☆
システムが実現すべき応答時間などのシステムの品質を明確にする工程として, 適切なものはどれか。
平成25年度 秋期 ITパスポート試験 問31
ストラテジ系システム企画 › 要件定義
This question's explanation and your answers so far.
解説
問 31
Incorrectア
System testing is the process of confirming, in an environment close to production, whether the developed system as a whole satisfies what was defined in requirements definition. Response time is also measured and verified in performance testing to see whether it meets the target value set as a requirement, but that means using an already clarified quality level as the criterion for judgment; the quality level itself is not decided here. This choice mixes up the process that clarifies requirements (the entrance) with the process that checks whether the requirements have been met (the exit).
- イ
正解 The correct answer is イ, System requirements definition. System development proceeds in the order planning → requirements definition → design → programming → testing → deployment and operation; requirements definition decides what to build, while design and the later processes decide how to build it. The requirements handled in requirements definition fall broadly into two kinds: functional requirements, which define the functions the system provides (what processing and what data it handles), and non-functional requirements, which define the level at which those functions are to be realized. The response time in the question is a typical example of the latter, the non-functional requirements; others include performance such as the number of transactions processed, availability such as the operating rate and the failure recovery time, security, extensibility, and ease of operation and maintenance. These quality levels required of the system must be agreed on and clarified by the users and the ordering side together with the development side in the system requirements definition process, which is the entrance to development. If they are not documented here as numeric targets, the design in later processes cannot secure the necessary performance, and testing has no criterion for judging pass or fail, which becomes a cause of rework. Therefore, the process that clarifies system quality such as response time is system requirements definition.
Incorrectウ
Software detailed design is the process that takes what was decided in requirements definition and system architectural design and makes the internal structure of the program (module division, processing procedures, data structures, details of input and output, and so on) concrete down to a granularity that can be programmed. Devising algorithms or ways of holding data in order to achieve the response time target may occur, but that is examining the means of realizing a given target value, not the process that sets the target value itself. The requirements are assumed to be already fixed as input to detailed design.
Incorrectエ
Programming is the process of writing code in a programming language based on the content of detailed design and confirming its operation with unit testing. What is done here is the work of building something that runs as designed; it is not the place to decide the quality levels required of the system. It is the implementation-stage process farthest from requirements definition, and if the response time target only began to be decided at this stage, implementation would proceed on a design that does not meet the requirements, causing major rework.
ここがポイント
- Requirements definition is the process that decides what to build, and requirements are divided into functional and non-functional requirements. Functional requirements are the content of the functions, processing, and data the system should have; non-functional requirements are quality-side demands such as performance (response time, number of transactions processed), availability (operating rate), security, extensibility, and operability and maintainability. Both are clarified in system requirements definition and should be agreed on in numbers as far as possible.
- The processes of system development proceed in the order planning → requirements definition (business requirements definition and system requirements definition) → system architectural design and software design (basic design and detailed design) → programming → testing (unit, integration, system, and operational testing) → deployment and operation. Grasp the difference in roles: requirements definition is the entrance process that decides, testing is the exit process that checks whether the requirements have been met, and design and programming lie in between, making concrete the means of realizing the requirements.
用語