AP22 — Requirements, UML, and Object-Oriented Design

Revised and source-checked: 2026-10-21

Learning index and syllabus map

This installment connects requirements to design without losing the reason for each artifact. Page numbers below distinguish the PDF page from the smaller printed footer page in the official IPA syllabus.

Learning index	IPA Ver.7.2 location	Scope used here
1. Requirements	PDF 62 / printed 58	System boundary; functional, performance, other functional/non-functional requirements; evaluation and review
2. Traceability	PDF 63 / printed 59	Bidirectional traceability, attributes-to-elements/test cases/information items, traceability matrix, use cases, UML
3. UML views	PDF 64 / printed 60	Requirements review; use-case, class, state-machine, and sequence diagrams
4. Requirements-to-design boundary	PDF 65 / printed 61	State-transition diagrams/tables and functional/non-functional design
5. Object-oriented design	PDF 68 / printed 64	Class, encapsulation, subclass, inheritance, polymorphism, association, generalization/specialization, decomposition, aggregation
6. Module design	PDF 69 / printed 65	Cohesion, coupling, module independence, data coupling, and control coupling

AP22 covers requirements, UML, and object-oriented design. AP23 covers testing, quality, and development methods; it will teach test design, which is only referenced here. AP24 is project management, AP25 service management, and AP26 audit, internal control, and security management.

Shared terminology table

The following table is deliberately identical in all three locale articles.

English	Korean	Japanese
functional requirement	기능 요구사항	機能要件
non-functional requirement	비기능 요구사항	非機能要件
bidirectional traceability	양방향 추적성	双方向トレーサビリティ
traceability matrix	추적성 매트릭스	トレーサビリティマトリクス
use-case diagram	유스케이스 다이어그램	ユースケース図
class diagram	클래스 다이어그램	クラス図
sequence diagram	시퀀스 다이어그램	シーケンス図
state-machine diagram	상태 머신 다이어그램	ステートマシン図
association	연관	関連
multiplicity	다중성	多重度
generalization	일반화	汎化
aggregation	집약	集約
composition	합성	コンポジション
encapsulation	캡슐화	カプセル化
inheritance	상속	継承
polymorphism	다형성	多相性
cohesion	응집도	結束性
coupling	결합도	結合度

One example from goal to design

We use a synthetic library-lending system throughout.

• R-F01 (functional): An eligible member can borrow an available copy and the system records the loan.
• R-N01 (non-functional): Under the stated synthetic test condition of 200 concurrent sessions, 95% of catalog-search responses complete within 2.0 seconds. This is an illustrative measurable threshold, not an IPA rule.
• Traceability chain: stakeholder goal → R-F01 → UC-01 Borrow Copy → LoanService.borrow and Copy.checkout → SD-01 → V-F01.

A functional requirement says what behavior the system supplies. A non-functional requirement constrains quality or operation; it becomes verifiable when its metric and condition are explicit. Bidirectional traceability is more than numbering artifacts: forward tracing supports impact analysis and coverage, while backward tracing shows justification and origin. A traceability matrix can record both directions. V-F01 identifies later verification work; AP23 will cover test design in full.

Four complementary UML views

Diagram	Purpose	Limitation
Use-case	Shows external actor goals and the system boundary	Does not show internal message order or data structure
Class	Shows static classes, attributes, operations, relationships, and multiplicities	Does not show runtime time order
Sequence	Shows messages in temporal order for one scenario	Does not show every possible lifecycle state
State-machine (state)	Shows states and event/guard-driven transitions of one entity	Does not show object structure

Use case:

[Member]    --> (UC-01 Borrow Copy)
[Librarian] --> (UC-02 Register Copy)

Class relationships:

Member    "1" -- "0..*" Loan
BookTitle "1" -- "0..*" Copy
Copy      "1" -- "0..1" activeLoan: Loan

Multiplicity is read at the opposite association end: the number near an endpoint states how many instances at that endpoint may link to one instance at the other end. Thus each Loan has exactly one Member, while one Member may have zero or more Loans. Each Copy has exactly one BookTitle, while one BookTitle may have zero or more Copies. Each active Loan concerns exactly one Copy, while one Copy has at most one active Loan. Historical loans are separate and may be many.

Relationship notation: association uses a solid line; generalization uses a hollow triangle pointing to the superclass; aggregation places a hollow diamond at the whole; composition places a filled diamond at the whole. Aggregation or composition cannot be inferred merely from “has-a.” Lifecycle and ownership semantics decide; an ordinary association is often correct.

Sequence SD-01:

Member -> UI: requestBorrow
UI -> LoanService: borrow
LoanService -> Copy: checkout
Copy -> Copy: validate Available; status := OnLoan
LoanService -> LoanRepository: save
LoanRepository --> LoanService --> UI --> Member: success

State machine for Copy:

Available --checkout--> OnLoan
OnLoan --return [undamaged]--> Available
OnLoan --return [damaged]--> Maintenance
Maintenance --repairComplete--> Available

The sequence is valid only when Copy.checkout begins in Available; a second checkout in OnLoan must be rejected.

Object orientation and module structure

• Encapsulation: Copy.status changes only through operations such as checkout, return, and repairComplete, which enforce valid transitions.
• Inheritance: a subtype inherits and extends characteristics of a supertype. For example, if BookTitle is a subtype of CatalogItem, it inherits the shared identifier and title; that generalization is sound only when a BookTitle can substitute for a CatalogItem. Inheritance is not always preferable to composition; choose by substitutability, ownership, and change needs.
• Polymorphism: LoanService calls NotificationChannel.send, while EmailChannel and PushChannel provide different implementations through one contract. This is overriding/runtime substitution, not overloading (multiple signatures with the same name).

High cohesion and low coupling generally support maintainability, but they are design guidance, not absolute universal laws or sufficient metrics by themselves. LoanService stays cohesive by focusing on loan decisions and lifecycle instead of unrelated reporting or UI work. Depending on the NotificationChannel interface reduces coupling to concrete channels. Data coupling passes needed values; control coupling passes a flag that dictates another module’s internal branch. Data coupling is generally less restrictive than control coupling.

Worked example A — classify, trace, and change

1. “An eligible member borrows an available copy and a loan is recorded” is R-F01, a functional behavior. “At 200 concurrent sessions, 95% of catalog searches finish within 2.0 seconds” is R-N01, a measurable non-functional quality condition, not an IPA threshold.
2. Record both directions in the matrix: goal ↔ R-F01 ↔ UC-01 ↔ LoanService.borrow/Copy.checkout ↔ SD-01 ↔ V-F01.
3. Suppose the rule changes so only members with no overdue loan are eligible. Forward impact tracing flags R-F01, UC-01, the eligibility logic in LoanService.borrow, SD-01 (including the rejection alternative if modeled), and V-F01. Backward tracing explains why each changed artifact exists. Copy.checkout and its state transitions should be inspected, but need not change if availability behavior is unchanged. R-N01 is not automatically impacted.

Worked example B — multiplicity and behavior

Read the endpoint beside Loan in Member "1" -- "0..*" Loan: one Member may link to zero or more Loans. Read the endpoint beside Member: each Loan links to exactly one Member. Reversing those readings incorrectly says that a Loan may have many members. Likewise, Copy "1" -- "0..1" activeLoan: Loan permits at most one active Loan per Copy; it does not limit a Loan to zero or one Copy—the opposite 1 says exactly one Copy per active Loan.

Replay SD-01: the request reaches Copy.checkout; Available --checkout--> OnLoan; then the repository saves and success returns. Replaying checkout while the Copy is already OnLoan finds no valid checkout transition, so the operation must reject it. Never reverse the state arrow or the endpoint interpretation.

Practice questions

Q1

Which statement is correct?

• ア. R-F01 is non-functional because it names a member.
• イ. R-N01 is functional because it mentions search.
• ウ. R-F01 describes behavior, while R-N01 states a measurable quality condition under 200 concurrent sessions; the threshold is illustrative, not an IPA rule.
• エ. A non-functional requirement cannot be measured.

Answer: ウ (3). ア confuses an actor with requirement type. イ ignores that response time constrains quality. ウ correctly classifies both and the synthetic threshold. エ is false because measurable conditions make verification possible.

Q2

Which diagram is best for showing messages in temporal order for one borrowing scenario?

• ア. Class diagram
• イ. Sequence diagram
• ウ. Use-case diagram
• エ. State-machine diagram

Answer: イ (2). ア shows static structure. イ shows scenario messages over time. ウ shows actor goals and boundary. エ shows one entity’s states and transitions.

Q3

What is the unique correct reading of Copy "1" -- "0..1" activeLoan: Loan?

• ア. One active Loan may concern zero or one Copy.
• イ. Every Copy must always have one active Loan.
• ウ. A Copy may have any number of active Loans.
• エ. Each active Loan concerns exactly one Copy, and each Copy has at most one active Loan.

Answer: エ (4). ア reverses endpoint meaning. イ turns 0..1 into mandatory 1. ウ ignores the upper bound. エ reads both opposite endpoints correctly; historical loans may still be many.

Q4

Which statement correctly distinguishes encapsulation and polymorphism?

• ア. Encapsulation makes Copy.status change only through valid operations; polymorphism lets LoanService call one NotificationChannel.send contract with different channel implementations.
• イ. Encapsulation means every field is public, and polymorphism means only overloading.
• ウ. Encapsulation is inheritance, and polymorphism is aggregation.
• エ. Both require LoanService to test every concrete channel type.

Answer: ア (1). ア states both concepts correctly. イ negates information hiding and confuses runtime overriding with overloading. ウ substitutes unrelated relationships. エ defeats substitution and increases concrete coupling.

Q5

Which design judgment is most appropriate?

• ア. Put reporting and UI rendering in LoanService to maximize cohesion.
• イ. Passing a branch-control flag is always less restrictive than passing required data.
• ウ. Keep LoanService focused and depend on NotificationChannel; data coupling is generally less restrictive than control coupling, though cohesion/coupling are not absolute laws.
• エ. Low coupling requires no module to communicate with another.

Answer: ウ (3). ア mixes unrelated responsibilities and lowers cohesion. イ reverses the usual comparison. ウ gives the balanced judgment. エ mistakes low coupling for zero interaction.

Answer key: 3, 2, 4, 1, 3 (ウ, イ, エ, ア, ウ)

Quick sheet

• Behavior → functional; measurable quality/constraint → non-functional.
• Trace both forward (impact/coverage) and backward (origin/justification).
• Use-case = actor goal; class = static structure; sequence = scenario order; state-machine = entity lifecycle.
• Read multiplicity from the opposite end.
• Hollow triangle → superclass; hollow/filled diamond → whole for aggregation/composition.
• Encapsulate valid state changes; polymorphism is runtime substitution, not merely overloading.
• Prefer focused responsibility and interfaces; distinguish data from control coupling.

Self-check and spaced review

Before stopping, can you classify R-F01/R-N01, reproduce the chain in both directions, state each diagram’s limitation, read all three multiplicities, replay SD-01 against Copy states, and explain encapsulation, runtime polymorphism, cohesion, and coupling?

• Day 1: redraw the four figures and answer Q1–Q5 without notes.
• Day 3: rebuild the traceability chain and explain both worked examples aloud.
• Day 7: answer all questions again; revisit any option whose rejection you cannot justify.

Official sources and notice

• IPA, Applied Information Technology Engineer Examination (Level 3) Syllabus Ver.7.2, PDF pages 62, 63, 64, 65, 68, 69 (printed pages 58, 59, 60, 61, 64, 65): https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kq5-att/syllabus_ap_ver7_2.pdf
• Object Management Group, Unified Modeling Language 2.5.1, About/specification and normative PDF.

Sources were checked on 2026-10-21. This independent study material is not affiliated with or endorsed by IPA or OMG. It does not guarantee examination success.