Functional vs Non-functional Requirements — The Overlooked Latter

In requirements definition meetings, the vast majority of discussion is spent on "what the system can do."

"We need a contact form." "We want filtering and search on the product listing page." "We'd like an admin panel for posting articles." These kinds of requests are easy for clients to visualize and straightforward for contractors to estimate. They can be captured in screen flow diagrams and feature lists, making alignment between parties relatively manageable.

But when someone asks: "Does that form need to complete submission within one second?" "Does it need to perform at the same speed when you have 10,000 products?" "What level of protection against unauthorized access and SQL injection do you require?" — the room goes quiet. The client says "I hadn't thought about that," and the contractor deflects with "we'll handle it with standard practices."

This is the structural cause of non-functional requirements being overlooked.

Clients bring three distinct biases to the table. First, the "as long as it works" completion mindset: the goal becomes having screens that function rather than asking "how fast" or "how securely." Second, the assumption that non-functional requirements are "included as a matter of course" — surely engineers do security as standard practice, so why specify it explicitly? Third, a lack of cost awareness around defining non-functional requirements: a preference for "let's just build it and adjust later" ends up functioning as a shortcut that skips proper agreement.

Contractors face structural problems of their own. Specifying non-functional requirements in detail drives up estimates. In a competitive pricing environment, "we'll deliver standard quality" becomes the pragmatic choice that wins contracts. And the implementation cost of non-functional requirements is harder to explain than functional ones. You can justify "hours to build the login feature," but "hours needed for session management vulnerability remediation" rarely lands with clients.

In this asymmetric information environment, projects routinely start without anyone documenting non-functional requirements — and that has become the norm.

Functional and non-functional requirements define different dimensions of a system.

Functional Requirements define what a system does. They cover the features users actually interact with, how data is processed, displayed, and stored, and screen navigation flows. Examples include: "users can register with an email address and password," "admins can bulk import product data via CSV," and "a confirmation email is sent automatically when an order is placed." These translate readily into specification documents, screen designs, and wireframes, and completion is relatively straightforward to verify.

Non-functional Requirements define how well a system operates. They specify quality conditions and constraints for realizing specific features — governing the overall behavior of the system rather than any individual function. Examples include: "the page loads within 3 seconds even with 1,000 simultaneous users," "personal data is encrypted at rest," and "a monthly uptime of 99.9% is guaranteed." These influence implementation methods and infrastructure design, but since they don't manifest directly on screen, the criteria for completion are also prone to ambiguity.

In short, functional requirements answer "what does it do?" while non-functional requirements answer "how well does it do it?" Using a restaurant analogy: "serving pasta" is a functional requirement; "serving it within 10 minutes at a temperature above 70°C" is a non-functional requirement.

The critical point is that a system without defined non-functional requirements can function in the short term. But when production load increases, a security incident occurs, or a failure needs recovery, the gaps in non-functional requirements surface all at once. Addressing them retroactively often requires redesigning the underlying infrastructure at many times the original cost.

Japan's Information-technology Promotion Agency (IPA) systematized non-functional requirements into six major categories in its Non-functional Requirements Grade framework: availability, performance and scalability, operations and maintainability, portability, security, and system environment and ecology. In web development and system development practice, these translate as follows.

1. Performance and Response (Performance)

Defines page display speed, concurrent connection capacity, and data processing throughput. Concrete examples include: "the top page initial load completes within 2 seconds," "response time does not degrade with 500 concurrent users," and "the monthly aggregation batch process completes between 3–5 AM." For e-commerce sites, where display speed directly affects conversion rates, defining performance requirements is tied directly to business metrics.

2. Reliability and Availability (Reliability / Availability)

Defines how continuously the system operates without stopping. Typical requirements include: "monthly uptime of 99.5% (unplanned downtime not to exceed 3.6 hours per month)," "recovery within 2 hours of a failure," and "daily data backups retained for 7 days." For services like e-commerce sites or reservation systems where downtime directly causes opportunity loss, these requirements connect to business continuity planning (BCP).

3. Security

Defines requirements for preventing unauthorized access, data breaches, and tampering. Examples include: "personal data stored encrypted with AES-256," "passwords hashed using bcrypt," "security measures addressing OWASP Top 10," and "account locked after 5 consecutive failed login attempts." Legal and standards-based requirements such as the Act on the Protection of Personal Information, compliance, and PCI DSS adherence also fall into this category.

4. Maintainability and Operability (Maintainability / Operability)

Defines requirements for maintaining and operating the system. Typical examples include: "error logs retained on the server for 30 days and accessible from the admin panel," "content updates performable independently by staff through the CMS," and "monthly release deployments completable within 1 hour." In contract development especially, clarifying who does what in the post-delivery operations phase from the outset is essential for preventing disputes.

5. Scalability and Portability (Scalability / Portability)

Defines design requirements for accommodating future growth and system changes. Examples include: "architecture that can handle 10x the current user count through server spec upgrades alone," "integration with existing core systems via API," and "infrastructure configuration that allows straightforward migration to a different cloud provider in the future." Sacrificing scalability to reduce upfront development costs typically results in enormous refactoring costs years later, making requirements that account for the business's growth trajectory essential.

6. Legal and Compliance Requirements (Compliance)

Defines legal requirements based on industry and business type. Systems handling medical information may require compliance with the Ministry of Health, Labour and Welfare's Guidelines for Safety Management of Medical Information Systems. Financial services require alignment with Financial Services Agency guidelines. E-commerce platforms may need PCI DSS compliance. These are invisible as features, but failing to address them exposes the business itself to legal risk — making them among the highest-priority non-functional requirements.

The following three scenarios illustrate what actually happens when non-functional requirements go undefined.

Scenario 1: Major Outage on Sale Day

An apparel brand's e-commerce site was built with requirements definition focused entirely on product registration, cart, and checkout functionality. No maximum concurrent connection limit was defined. The system worked fine with the typical 100 concurrent users, leaving both parties complacent. On the first day of a seasonal sale, a simultaneous SNS campaign drove thousands of users to the site at once. The site stopped responding within 15 minutes. Emergency server spec upgrades were performed, but because the database index design hadn't anticipated load, the outage continued for over half a day. The combined opportunity loss and recovery costs exceeded the original development budget. Had performance and scalability requirements been defined, load testing and infrastructure design review would have been conducted from the start.

Scenario 2: Reputation Collapse from Personal Data Breach

A membership service system was developed for a small and medium-sized enterprise. The client said "handle security as you see fit," and the contractor replied "we'll implement standard measures." In practice, passwords were stored in plaintext and SQL injection protection was inadequate. A year after launch, an unauthorized access incident exposed several thousand member records. The client argued that no security requirements had been specified; the contractor countered that they had implemented standard practices given the absence of explicit requirements. The dispute over liability dragged on and the relationship between the parties was irreparably damaged.

Scenario 3: Black-Box System After Staff Turnover

A system was built in a near-insourced contract development arrangement. At the client's request to minimize time and cost, almost no maintainability requirements were defined. When the contractor — a freelancer — left the project a year later, the source code had almost no comments and there was no documented environment setup procedure. Every subsequent modification and improvement required enormous analysis overhead, with small bug fixes sometimes costing hundreds of thousands of yen. Maintainability requirements such as "50% or more of code commented," "environment setup documentation delivered," and "error logging implemented" would have prevented this situation.

For non-functional requirements to function effectively, they must be captured in a written agreement — verbal confirmation is insufficient.

Step 1: Use IPA's Non-functional Requirements Grade for Systematic Elicitation

is a practical tool for systematically eliciting non-functional requirements. Publicly available question lists covering each of the six categories — along with graded tables showing requirement levels — can be used as a basis for both client and contractor to review requirements together at the start of the project.

Step 2: Agree on Priorities and Target Levels

Implementing every non-functional requirement at the highest standard is not realistic. To structure the cost-quality tradeoff, agree on the priority (required / recommended / defer to future phase) and specific numerical targets for each category. For example, document agreements such as "99% uptime is sufficient, but security is the top priority" or "performance needs to support up to 3x our projected user count." These should be captured in writing.

Step 3: Reflect Non-functional Requirements in Estimates and Contracts

Once the level of non-functional requirements is established, implementation costs can be explicitly stated in estimates. Presenting items like "Security measures: ¥XXX,000 (includes OWASP Top 10 compliance and penetration testing)" in a form the client can understand creates accountability for what costs what. The contract should include a clause stating that "non-functional requirements for this engagement are as specified in Appendix X, and addressing requirements beyond that scope will be separately estimated," which protects against being asked for unpaid additional work.

Step 4: Define Acceptance Criteria and Verify Against Them

Because non-functional requirements are difficult to judge as "complete," acceptance criteria should be defined as specific numerical values and test procedures. Write these in measurable form: "confirmed via load test that response time stays within 3 seconds with 500 concurrent connections," "confirmed zero high-risk findings via OWASP ZAP vulnerability scan." Requiring evidence that these criteria have been met prior to delivery should be a contractual condition.

What Clients Can Do Right Now

Start by mapping out the business risks of your service. Think concretely about what happens if the system goes down, if data is leaked, or if slow performance drives users away. The magnitude of those risks determines the appropriate level of non-functional requirements.

Next, build the habit of asking contractors: "How do you define and ensure non-functional requirements?" A contractor who can't answer clearly is likely treating them as an afterthought. One who responds systematically demonstrates a strong quality mindset.

Finally, reframe investing time and money in defining non-functional requirements as exactly that — an investment. Spending an additional ¥500,000 on requirements definition is insurance against a production outage that could cost millions in opportunity losses.

What Contractors Can Do Right Now

Include non-functional requirement check items in every intake questionnaire as standard practice. Questions like "How many simultaneous users do you anticipate?", "Does the system handle personal information?", and "What is the maximum acceptable downtime?" normalize these conversations and raise client awareness of non-functional requirements.

In estimates, explicitly list the cost of non-functional requirement compliance and note the risks of omission. A line like "This estimate does not include load testing. If anticipated traffic increases, additional work will be required" protects against being held responsible for situations that were never contracted.

And leading with "Here are the minimum non-functional requirements for a service of this scale" during the proposal phase is a powerful differentiator. Rather than competing solely on price, contractors who can articulate quality and security risks are positioned as long-term partners — and that's a compelling proposition.

---

References

Non-functional Requirements Grade 2018 (2018)

Non-functional requirement (2024)

非機能要件 (2024)