1.4Defining non-functional requirements

If non-functional requirements are agreed to while still phrased in vague terms such as "good performance" or "high security," a mismatch in understanding—"that's not what we meant"—surfaces once development is underway, triggering major rework. A system architect is required to have the ability to spot signs of vague non-functional requirements, translate them into measurable indicators (concrete figures and acceptance criteria), and build stakeholder consensus around them.

1.4.1The non-functional requirements grade

• The non-functional requirements grade, published by IPA, is a tool and framework that systematizes non-functional requirements into major categories—availability; performance/scalability; operations/maintainability; migratability; security; system environment/ecology—and lets an achievement level (grade) be selected for each item. It is used to build consensus on non-functional requirements with stakeholders, comprehensively and efficiently.
• The greatest benefit of using the non-functional requirements grade is that it lets you comprehensively cover items users are unlikely to think of on their own (such as disaster-recovery measures or the detailed level of security). However, merely filling in the grade mechanically is not enough; it is the system architect's role to select each grade in light of business importance, cost, and feasibility, and to be able to explain the rationale to stakeholders.

1.4.2Measurable agreement on performance, reliability, availability, and security requirements

• Performance requirements should be agreed to down to concrete figures and the measurement condition (normal load or peak load, etc.)—"response time within X seconds," "processing X transactions per second at peak." Reliability/availability requirements should quantify the tolerance for a failure—"availability of X%," "RTO (recovery time objective) within X hours," "RPO (recovery point objective) within X minutes."
• Security requirements should be translated into concrete acceptance criteria—the required authentication method, the granularity of access control, the audit-log retention period, the frequency of vulnerability scanning—rather than left as the vague phrase "make security high." For every non-functional requirement, the key to preventing rework is not stopping at quantification but explaining the rationale behind the figure (business impact, cost justification) to stakeholders and obtaining their agreement.

Suppose you are the system architect for the renewal of an online reservation service, and during requirements definition a stakeholder requests, "please make sure the system doesn't go down as much as possible" and "make security solid." It is dangerous to record this request as-is in the requirements document using the vague words "high availability" and "high security" and call it agreed, because agreeing while the wording stays vague lets a mismatch in understanding—"that's not the level we meant"—surface once development is underway, triggering major rework in the form of a design do-over. The appropriate approach is to first, following the availability and security items of the non-functional requirements grade, ask stakeholders concrete questions such as "how much would business be affected if the service went down (for example, how much lost opportunity would result if reservations couldn't be accepted)?" and "how long a recovery time would be tolerable?". From the answers, translate this into a measurable, agreed figure—for example, "availability of 99.9% or higher, with an RTO (recovery time objective) within 1 hour upon a failure." Likewise for security, agree to concrete acceptance criteria, such as "because payment information is handled, comply with a PCI-DSS-equivalent standard and require multi-factor authentication." At this point, casually setting an excessively high target such as 99.99% availability would send the cost of a redundant configuration soaring, so it is also essential to verify, weighed against cost, whether the requested availability level truly matches the business impact, and to explain the rationale to stakeholders. Rather than "non-functional requirements cause no trouble later even if agreed to in conceptual wording," the core of defining non-functional requirements is translating a vague request into measurable figures and acceptance criteria, and building consensus that includes their cost justification.

1.4.3Section summary

• Use the non-functional requirements grade to comprehensively cover non-functional requirements, including items users are unlikely to think of
• Agree on performance, availability (RTO/RPO), and security as measurable figures and acceptance criteria, not vague wording
• Verify the target level against business impact weighed with cost and explain the rationale to prevent both rework and over-engineering