Don't Forget to Decide 'How Many Seconds Is Fast Enough' — Organizing Non-Functional Requirements With IPA's Non-Functional Requirements Grade

“We were told the screen transitions are too slow, but neither the contract nor the spec document has any agreement on response time.”

“The overnight batch job stopped finishing before morning, but nobody had ever estimated how much the data volume would grow over the years.”

“Only after a server failure took the system down for half a day did we realize nobody had confirmed, at the time of ordering, how many hours the configuration was actually built to recover within.”

When people think of system-development trouble, a mismatch over functionality usually comes to mind, but disputes that actually flare up once operations begin are, quite often, the result of forgetting to decide these non-functional requirements — the requirements that aren’t about function at all.

The public tool that exists to prevent exactly this kind of oversight is the Non-Functional Requirements Grade from IPA (the Information-technology Promotion Agency, an independent administrative institution). This article lays out what’s actually in it, and a realistic way to use it for an SME’s business system, in language a client can follow too.

1. The Bottom Line First

• Non-functional requirements aren’t about “what the system does” — they’re about “how well and under what conditions it operates.” They can be organized into six areas: availability, performance, operations, migration, security, and installation environment.
• The Non-Functional Requirements Grade is a (free) set of IPA tools that exhaustively lists the requirement items across these six areas and lets clients and developers align on them at staged levels.
• You don’t need to fill in every item. The intended usage is to pick the “model system” closest to your own, then adjust the important items first to match your real circumstances.
• The higher you set a non-functional level, the more it costs. Rather than “vaguely demanding a high standard,” choose the level by working backward from the impact on your business.
• Keep the decisions in the requirements-definition document. The assumptions fixed there are what let you compare quotes fairly and prevent “he-said-she-said” disputes once the system is in operation.

2. What Non-Functional Requirements Are — What Sits Between “It Runs” and “It’s Usable”

Functional requirements are things like “can register an order” or “can print a report” — requirements about what the system does. Development meetings naturally gravitate toward this kind of discussion.

Questions like the following, on the other hand, never show up on a list of functions.

• What hours does this system need to be up? What about weekends? During the overnight batch job?
• If it goes down, within how many hours does it need to recover before the business stops functioning? How far back can the recovered data acceptably go?
• How many people use it at once, and how many transactions does it process per day? How much will the data volume have grown in five years?
• Who monitors it, takes backups, and receives the first report of a failure?
• How much of the old system’s data gets carried over to the new one?

These are the non-functional requirements. What makes them tricky is that the system will, more or less, “run” even if you never decide any of them. The problem only surfaces once operations start, load grows, and a failure actually happens — and by that point, because it touches the fundamentals of the server configuration and design, fixing it costs a great deal.

3. What the Non-Functional Requirements Grade Is

The Non-Functional Requirements Grade is a set of tools IPA publishes with the aim of preventing clients and developers from talking past each other over non-functional requirements. The first version came out in April 2010, and the current latest version, reflecting changes around security and virtualization (the cloud), is “Non-Functional Requirements Grade 2018,” published in April 2018. It now sits on an archived page on IPA’s site, but it’s still the standard reference used in practice for checking that no non-functional requirement has fallen through the cracks.

It’s made up of the following set of tools.

Each metric has a defined set of staged levels to choose from, which means a requirement can be expressed as a choice of level rather than a vague word like “high” or “low.”

The Three Model Systems

Another feature is the three model systems, split by how large a societal impact the system’s downtime would cause.

• Systems with almost no societal impact
• Systems with limited societal impact (such as a company’s core business systems)
• Systems with an extremely large societal impact (such as social infrastructure)

The grade table already has a baseline level filled in for each model. In other words, instead of starting the discussion from zero, you can first identify “we’re closest to this model,” and then dial the levels up or down to match your own circumstances.

4. The Six Major Categories — Translated Into the Client’s Language

Recast as questions a client can actually answer, the Non-Functional Requirements Grade’s six major categories look like this.

Seen this way, it’s clear that most of the six major categories are business questions, not technical ones. Who can answer “what happens if the month-end billing run is delayed by half a day” is the client, not the development company. The initiative on non-functional requirements actually belongs to the client.

5. A Realistic Way to Use It — Don’t Try to Fill In All 238 Items

The item list has 238 metrics, but discussing every single one isn’t realistic for an SME project, and the usage guide doesn’t assume you’ll use it that way either. The intended flow looks like this.

1. Choose a model system
   (which impact level is your system closest to?)
        ↓
2. For the important items in the grade table,
   adjust from the model's baseline level to fit your own circumstances
        ↓
3. Drill down into the item list only for the parts that need it

For an SME’s business application, just Step 2 — aligning on the important items — already delivers plenty of value. In my experience, I’d recommend documenting at least the following points during requirements definition.

• Operating hours, and the business impact if the system goes down (availability)
• The backup interval, and, in a failure, “data restored up to what point in time” and “within how many hours” (availability / operations)
• The current data volume/record count and the projection a few years out (performance / scalability)
• Target values for response time and batch-processing time. Even “at least as fast as the current system” is fine, as long as a baseline is set (performance)
• Who is responsible for monitoring, backups, and first response to a failure (operations / maintainability)

The thing not to forget here is the tradeoff between level and cost. Aim for “a system that absolutely never goes down,” for instance, and the cost jumps sharply because of server redundancy and monitoring infrastructure. If you can instead judge that “as long as the business can wait until the next morning, recovering by the end of the day is enough,” you can redirect that budget elsewhere. The right way to hold the Non-Functional Requirements Grade’s levels isn’t as a tool for demanding more — it’s as a shared language for discussing the balance between business impact and cost.

6. The Relationship With Contracts and Quotes

Non-functional requirements also connect directly to the contract.

First, there’s comparing quotes. Get quotes from multiple companies without aligning on non-functional assumptions, and Company A might be pricing a redundant configuration while Company B prices a single server. The client loses the ability to tell whether a difference in price reflects a difference in configuration, or just an overly optimistic estimate.

Next comes acceptance testing and life after the system goes live. With response time and backup arrangements written down, a back-and-forth of “it’s slow” versus “we didn’t expect that” turns into simply checking the facts against an agreed standard.

IPA’s Information System Model Transaction and Contract likewise assumes that non-functional requirements get documented as a deliverable of the requirements-definition phase. The Non-Functional Requirements Grade fits naturally into a multi-stage contract flow where requirements definition is done under a quasi-mandate contract and, once the content is settled, development proceeds under a contract for work. For more on that contract structure, see our article on IPA’s Model Contract.

Summary

Here’s a recap of the key points about IPA’s Non-Functional Requirements Grade.

• Non-functional requirements are about how well and under what conditions a system operates. It runs even without deciding them, but the gaps surface as disputes once it’s in operation
• The Non-Functional Requirements Grade is IPA’s free set of tools for aligning, at staged levels, six major categories — availability, performance/scalability, operations/maintainability, migratability, security, and system environment — spanning 238 metrics
• Start from the baseline levels of the three model systems and adjust the important items first. You don’t need to fill in every item
• The content of the six major categories is mostly business questions. The client is the one who holds the answers
• The higher the level, the higher the cost. Choose the balance by working backward from the business impact, and record the result in the requirements-definition document

Decide, ahead of time, “what quality it needs to keep running at” just as much as “what to build.” That’s the cheapest way to prevent both a system that runs but isn’t usable, and the disputes that follow.

If You’re Struggling to Organize Requirements for a Business System

Reconciling non-functional requirements takes going back and forth between the real state of the business (peak periods, data volume, the impact of downtime) and the system configuration that has to deliver on it.

Komura Software LLC, when consulting on contract development or modification of Windows business applications and web systems, works with clients to organize performance, operations, and failure-time behavior at the requirements stage, following the thinking introduced in this article. We’re happy to talk even at the stage of “our current system has been gradually getting slower” or “we’d like to revisit our operational arrangements while we’re updating things.”

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What are non-functional requirements?

They are requirements about how well and under what conditions a system operates, as opposed to functional requirements, which cover what the system does. Examples include when the system needs to be available (availability), how many concurrent users it must support and how fast it must respond (performance and scalability), who operates and maintains it and how (operability and maintainability), how data gets carried over from the old system (migratability), what defenses it needs (security), and what environment it's installed in (system environment). Forget to decide these, and you tend to end up with a system that runs but isn't actually usable.

Can I use the Non-Functional Requirements Grade for free? Where do I get it?

Yes, you can download it free of charge from IPA's website. It comes as a set: a grade table, an item list, a tree diagram, a worksheet, and a usage guide (in explanation, usage, and application volumes). The current version is 'Non-Functional Requirements Grade 2018,' published in April 2018. It now sits on an archived page on IPA's site, but it's still widely used in practice as the standard for checking that no non-functional requirement has been overlooked.

Do I have to decide all 238 items?

No. Even the usage guide doesn't assume you'll discuss every metric one by one. The staged approach it lays out is: first pick the model system closest to your own to set an overall baseline, then adjust the important items in the grade table to match your actual circumstances, and only drill down into the item list for the parts that need it. For an SME's business system, just reconciling the important items is enough to head off most of the disputes that come from forgetting to decide something.

When should non-functional requirements be decided?

At the requirements-definition stage. Availability and performance targets touch the fundamentals of the server configuration and design, so changing them once development is underway has a major impact on cost and schedule. IPA's Information System Model Transaction and Contract likewise assumes that non-functional requirements, not just functional requirements, get documented as a deliverable of the requirements-definition phase. If you don't align on non-functional assumptions before comparing quotes, you can no longer tell whether a difference in price reflects a difference in configuration or just an overly optimistic estimate.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.