IPA Non-Functional Requirements Grades: A Practical Guide to System Quality
Section titled “IPA Non-Functional Requirements Grades: A Practical Guide to System Quality”A system needs more than working features. It must handle demand, recover from failures, protect information, and remain manageable throughout its life.
IPA’s Non-Functional Requirements Grades provide a structured way to discuss and agree on the quality and constraints of a system. Developed by Japan’s Information-Technology Promotion Agency, the publicly available materials help business stakeholders and delivery teams identify requirements that might otherwise be overlooked.[1]
The approach is useful outside Japan: start with business consequences, define measurable expectations, and connect them to engineering and operational evidence. This article combines an explanation of IPA’s framework with practical guidance. All numerical targets and implementation examples below are illustrative; they are not universal IPA requirements.
What are non-functional requirements?
Section titled “What are non-functional requirements?”Functional requirements describe what a system does. Non-functional requirements describe the quality and conditions under which it must do it.
| Business capability | Functional requirement | Non-functional requirement |
|---|---|---|
| Ordering | Customers can submit orders | Order submission meets its response-time target under peak demand |
| Customer records | Staff can create and search records | Only authorized staff can access records, and important actions are traceable |
| Reporting | The system generates daily reports | Reports finish before the next business day and failed jobs can be rerun |
| Online service | Users can perform tasks through a website | The service is available during agreed hours and recovers within the tolerated outage window |
“Non-functional” does not mean optional or unrelated to the business. A complete feature set cannot compensate for a service that is too slow, regularly unavailable, insecure, or impossible to recover. These requirements affect customer experience, continuity, trust, and operating costs.
This article treats a stakeholder’s need as a starting point and an agreed, specific condition as the resulting requirement. IPA’s materials help teams move from the former to the latter.
What does the framework provide?
Section titled “What does the framework provide?”IPA organizes non-functional requirements into categories and provides selectable requirement levels to reduce misunderstandings between stakeholders and developers.[1]
“Make it reliable” is insufficient for estimating cost, choosing architecture, or accepting delivery. Teams must identify the relevant service, operating hours, failure scenarios, workload, and recovery expectations.
The framework is a tool for agreement, not a certification scheme or a single score for an entire system. Level numbers have item-specific meanings. Selecting “level 3” everywhere would not adequately describe system quality. Read each level’s definition and agree on concrete values and conditions.[4]
Choose levels that fit business impact, risks, budget, and staffing. Higher requirements can increase both implementation costs and the work needed to operate the service.
Why its coverage matters
Section titled “Why its coverage matters”Experience alone can produce uneven requirements. A team may consider throughput and security while overlooking migration rollback, restore testing, or support coverage.
IPA’s framework is valuable because it gives teams a broad, organized view of system infrastructure requirements. It supports a checklist in which every item is considered, deliberately excluded, or assigned for further decision.[2]
It is not an exhaustive catalogue of every possible non-functional requirement. Its primary focus is infrastructure. Add relevant requirements for usability, accessibility, application-specific quality, and your industry’s or contracts’ particular conditions.[4]
Six categories: decisions and actions
Section titled “Six categories: decisions and actions”IPA defines six major categories.[2] The decisions, actions, and consequences in this table are practical examples developed for this article.
| Category | Decide | Implement and verify | Consequence of leaving it unclear |
|---|---|---|---|
| Availability | Service hours, planned downtime, availability targets, recovery time, tolerable data loss | Identify single points of failure; provide appropriate redundancy; test failover, restoration, and disaster recovery | Outages exceed business tolerance, with uncertain recovery and data loss |
| Performance and scalability | Normal and peak workload, response targets, batch deadlines, data growth, expansion conditions | Run load tests; plan capacity; improve application and database performance; test expansion procedures | Growth causes timeouts, delays, and missed processing deadlines |
| Operability and maintainability | Monitoring, response coverage, responsibilities, backup operations, maintenance, support | Establish alert routing, on-call coverage, runbooks, restore tests, patch procedures, and change rollback | Failures go unnoticed or remain unresolved; changes cannot be recovered safely |
| Migratability | Assets and data to move, migration approach, permitted downtime, validation, rollback conditions | Rehearse migration and rollback; measure duration; reconcile records, amounts, and relationships; define go/no-go criteria | Data is lost or inconsistent, downtime overruns, or the old service cannot be restored |
| Security | Assets, threats, permissions, authentication, encryption, auditability, detection, response | Apply least privilege and appropriate MFA; manage keys and secrets; address vulnerabilities; test audit logging and incident response | Unauthorized access, disclosure, untraceable activity, or expanding damage |
| System environment and ecology | Usage and installation constraints, applicable standards, facility conditions, environmental impact | Check power, temperature, and space constraints; right-size resources; review unnecessary consumption | Deployment conditions cannot be met, facilities lack capacity, or resources are wasted |
All six categories remain relevant in the cloud. Providers manage some physical facilities, but customers still make decisions about configuration, data protection, monitoring, and recovery. Record your responsibilities, the provider’s responsibilities, and which requirements are satisfied by the provider’s documented service conditions.
Which materials should you use?
Section titled “Which materials should you use?”The Japanese 2018 package includes usage guides, a grade table, an item list, tree diagrams, and a utilization sheet.[1]
| Material | Practical use |
|---|---|
| Usage guides | Understand the framework and its method |
| Grade table | Establish a starting point for important requirements using representative system models |
| Item list | Review detailed requirements and reduce omissions |
| Tree diagrams | See the overall structure and relationships |
| Utilization sheet | Record and customize selected requirements for your project |
The official English package is linked at the end of this article. IPA lists it under the initial edition, separately from the Japanese 2018 edition. Do not assume it is a complete translation of the 2018 revision.[1][3]
A workflow you can apply
Section titled “A workflow you can apply”IPA’s basic sequence is to select a model system, decide levels for important items, and then decide levels for the remaining items.[1] The following workflow extends that sequence into implementation, acceptance, and operations.
1. Establish scope and business impact
Section titled “1. Establish scope and business impact”Bring together the business owner, application engineers, infrastructure engineers, operations, and security. Record:
- Services, users, operating hours, and external dependencies.
- Normal and peak demand, data volumes, and expected growth.
- Consequences of downtime, latency, data loss, and disclosure.
- Budget, delivery constraints, staffing, contractual conditions, and internal policies.
Avoid choosing architecture before agreeing on the outcomes it must deliver.
2. Select a model and adjust important requirements
Section titled “2. Select a model and adjust important requirements”IPA provides three representative models: systems with almost no social impact, limited social impact, and very significant social impact.[2]
Use the closest model as a discussion starting point. Assess the consequences of failure rather than choosing solely by organization size.
Resolve architecture-sensitive requirements early: service hours, recovery objectives, peak demand, security controls, operating coverage, and migration downtime. Adjust model defaults to your actual needs.
3. Review the detailed items and contradictions
Section titled “3. Review the detailed items and contradictions”Mark each item as adopted, not applicable, or undecided. Explain exclusions; assign an owner and deadline to undecided items.
Look for conflicting assumptions, such as:
- A service operates overnight, but nobody handles overnight incidents.
- A short recovery objective depends on a restore process that takes hours.
- No data loss is allowed, but recent updates cannot be recovered from backups.
- Peak throughput is promised without checking an external API’s limits.
4. Write measurable requirements and acceptance criteria
Section titled “4. Write measurable requirements and acceptance criteria”Replace vague adjectives with scope, conditions, targets, and verification methods.
The examples below describe a fictional web service. Replace the values with those justified by your business.
| ID | Example requirement | Verification |
|---|---|---|
| NFR-A01 | Achieve at least 99.9% monthly availability for key customer operations. Define measured operations, success criteria, and treatment of planned downtime | Calculate results from synthetic customer journeys and incident records using the agreed method |
| NFR-P01 | Under an agreed data volume and operation mix, sustain 100 requests/second for 30 minutes, with search API p95 latency no higher than 2 seconds and an error rate below 0.1% | Load-test a production-representative environment; inspect latency, errors, and resource use |
| NFR-A02 | For the agreed database failure scenario, meet a 60-minute RTO and a 15-minute RPO. Define when timing starts and what counts as business recovery | Run a recovery exercise; record elapsed time and the latest recoverable data point |
| NFR-O01 | During service hours, route monitoring alerts to responsible staff and begin initial assessment within 15 minutes of notification | Test alert delivery and response; record notification and acknowledgement times |
| NFR-M01 | Keep migration downtime within 2 hours; reopen only after critical data reconciliation passes. Define rollback triggers for overruns or failed reconciliation | Rehearse migration and rollback; review timing and reconciliation evidence |
| NFR-S01 | Require MFA for interactive administrator logins and retain audit logs of privilege changes and critical actions. Agree on retention and access permissions | Test login rejection without MFA, authorization, log generation, and retrieval |
| NFR-E01 | Meet agreed hosting-site power, temperature, and space constraints; review excess resource allocations quarterly | Inspect facility and configuration requirements; review measured resource use |
p95 latency is a value at or below which 95% of measured response times fall. Also examine slower requests and errors; the percentile alone does not describe the entire experience.
RTO (Recovery Time Objective) specifies the target time to restore service. RPO (Recovery Point Objective) specifies the data point to which recovery is required. A 15-minute RPO represents an intention to tolerate up to 15 minutes of lost updates before the disruption.
Recovery speed and data loss are different requirements. Define both, along with the relevant failure scenarios.
5. Connect requirements to architecture, cost, and staffing
Section titled “5. Connect requirements to architecture, cost, and staffing”For each requirement, document the implementation approach, owner, cost, assumptions, and dependencies. Validate the complete business operation rather than assuming that a particular managed service or deployment pattern guarantees the outcome.
Redundancy may help with hardware failure but does not guarantee recovery from accidental deletion. Backups require successful restore tests and measured restore times.
For external dependencies, establish rate limits, outage behavior, retry rules, duplicate-processing prevention, and escalation contacts. Account for these in both design and testing.
6. Verify, accept, and revisit
Section titled “6. Verify, accept, and revisit”Map requirement IDs to design decisions, acceptance tests, and operational measurements. Where a target cannot be met, record the design change, requirement change, or approved remaining risk before deciding to launch.
Reassess requirements when demand, architecture, incident experience, or staffing changes. Agreed requirements should remain a basis for checking the live service’s quality.
Your first deliverable: a requirements register
Section titled “Your first deliverable: a requirements register”A spreadsheet or Markdown table can be sufficient to start.
| Field | Record |
|---|---|
| Identity and scope | Requirement ID, relevant IPA item, service or business process |
| Target | Selected level, its actual meaning, specific target, measurement conditions |
| Rationale | Business impact, selection reason, or reason for exclusion |
| Implementation and responsibility | Design approach, owner, dependencies, cost |
| Verification | Test method, pass criteria, results, operational measurement |
| Open decisions | Undecided items, deadlines, remaining risks, approver, approval date |
The goal is an agreed quality baseline that the team can implement and verify. A completed checklist is useful only when it leads to those decisions and evidence.
Official resources and English download
Section titled “Official resources and English download”The materials are publicly available. IPA’s introduction page is now an archive and the associated project has ended. The older publication dates do not prevent using the approach, but adapt implementation choices to your current technology and requirements.[1]
- Download the official Non-Functional Requirements Grades English package (ZIP). It contains English guides and tools and is listed by IPA under the initial edition.
- Download the Japanese Non-Functional Requirements Grades 2018 package (ZIP).
Sources:
- IPA introduction and download page (Japanese).
- IPA practical seminar materials (Japanese PDF).
- IPA 2018 revision information (Japanese PDF).
- IPA, Non-Functional Requirements Grades Usage Guide — Description Manual, included in the official English ZIP package linked above. Relevant explanations include scope and requirement-level interpretation.
Check the usage conditions linked from IPA’s introduction page before reproducing or modifying its materials. This article is an independent explanation and practical guide, not an official IPA translation.