※ Our check while writing this explanation could not fully confirm the published answer; scoring follows IPA's official key.
×Incorrectア
(3) and (7) really are requests, but (2), “If we use commercially available software, the system introduction cost should become cheaper”, is wrong. This is not about something that would be convenient to do in the travel expense application work; it is an opinion about how to build the system (using packaged software instead of in-house development) and about the cost side, namely how the introduction cost would change as a result. Views on the implementation method or on cost are matters handled when procurement and development policy are examined after the requirements have been gathered, and they must be kept distinct from requests that belong to the business requirements. Therefore ア, which includes (2), is inappropriate.
×Incorrectイ
(3) is correct as a request, but two items, (6) and (9), are wrong. (6), “Even after the system is introduced, deficiencies and mistakes in application documents are corrected by the applicant and submitted again”, is not a wish that something be done in a certain way; it confirms an operating rule and a premise, namely that this procedure will not change even after the system is introduced, so it is not a request. (9), “Please hold a briefing session when the system is introduced”, does take the form of a request, but what it targets is how training and communication are carried out at introduction time, not a request for a system function of the kind “it would be convenient if this could be done when applying for travel expenses”. Since both items miss the mark, イ is clearly inappropriate.
○ウ
正解The correct answer is ウ, “(3), (7), and (8)”. Items (1) to (9) in the [System Introduction Review Meeting Memo] can be sorted by their content into the following three kinds. First, the “current problems”, which report facts about what actually troubles people now. Second, the “requests for the system”, which say it would help if the new system could work in a certain way. Third, opinions that belong not to the travel expense application work itself but to how the project is run, such as the estimated introduction cost, the operating rules after introduction, and the way the introduction is carried out. This question asks about the second kind, the requests, so you only have to judge item by item which of the three groups each one falls into. The clue for telling them apart is the end of the sentence. (3) “It would be fine to have a way to apply for several days at once”, (7) “I would like to apply by reusing data that was applied for in the past”, and (8) “It would be good to know when the travel expenses applied for will be paid after the application” all end in wish forms such as “it would be fine to have”, “I would like to”, and “it would be good to know”, and none of them reports a fact about a present difficulty. Moreover, all three are about functions of which you can say “it would be convenient if this could be done” within the travel expense application work: batch application, reuse of past data, and checking the payment schedule. In other words, the wording of the question applies to them directly. Therefore ウ, which lists (3), (7), and (8), is correct. Note that these items will later be organized as functions the system should have, that is, as candidates for functional requirements. Conversely, (1), (4), and (5) — “spends the most time”, “there are many deficiencies”, and “it takes time” — all state facts that are occurring now and are therefore current problems; they correspond to the answer (イ) of the sister question, Q89.
×Incorrectエ
(7) and (8) are correct as requests, but (9), “Please hold a briefing session when the system is introduced”, is wrong. (9) concerns how the introduction project is run, that is, a request on the training and transition side for a briefing session for users, not a function that they want realized within the travel expense application work. The question limits its scope with the words “such as it would be convenient if this could be done when applying for travel expenses”, so (9), which is not tied to a business function, is excluded. In addition, エ is insufficient because it drops (3), which is a clear functional request for batch application.
ここがポイント
The first step of business requirements definition is to sort what the stakeholders say into “current problems” (facts about what troubles them now) and “requests for the system” (expectations of how they would like things to be). You can judge this almost mechanically: if the ending is a factual report such as “there are many …” or “it takes a lot of time”, it is a problem; if it is a wish form such as “I would like to …”, “it would be fine to …”, or “it would be good to know …”, it is a request.
Even among requests, distinguish between functions they want realized within the business work (candidates for functional requirements) and opinions about how the introduction is carried out or how things are operated, such as introduction cost, implementation method, or briefing sessions. Reading which of the two scopes the question is asking about is what leads to scoring points in this kind of grouped question set.