What's changed: Initial version
5.2Requirements definition & non-functional requirements
Covers the distinction among business requirements (what the business must achieve), functional requirements (what the system realizes), and non-functional requirements (quality and constraints such as performance, availability, and security); the judgment of agreeing with users on the tradeoff between availability level and cost using IPA's non-functional requirement grades (availability / performance-extensibility / operability-maintainability / migratability / security / system-environment-ecology); and securing stakeholder requirements, requirements analysis, and traceability.
In requirements definition, "what the business wants to achieve," "what the system does for it," and "at what quality and constraints to realize it" are clarified while agreeing with stakeholders. These are distinguished as business requirements, functional requirements, and non-functional requirements; confusing them leaves "what a feature is for" and "how much quality is needed" vague downstream. Non-functional requirements in particular involve tradeoffs—raising availability raises cost—so it is important to show levels in stages using a framework like IPA's non-functional requirement grades and agree with users. This section covers the strategist's viewpoint of separating requirement types, judging non-functional tradeoffs, and bundling stakeholder requirements while preserving traceability.
5.2.1Distinguishing business, functional, and non-functional requirements
- Business requirements are what the business must achieve as the purpose of systematization (e.g., "shorten the order-to-shipment lead time"). Functional requirements are the functions the system provides to realize them (e.g., "register, look up, and update order data"). Non-functional requirements are the quality and constraints under which functions are met—performance, availability, security, extensibility, operability (e.g., "online response within 3 seconds," "99.9% uptime").
- The point of separating the three is downstream traceability and agreement. Business requirements are the rationale for functional and non-functional requirements; listing only functions drops "why the function is needed" and "at what quality it is met." Folding non-functional into functional requirements blurs the agreement on quality levels and the cost estimate.
5.2.2Non-functional requirement grades and agreeing on tradeoffs
- The non-functional requirement grades (IPA) is a framework that assesses and presents non-functional requirements in stages (grades) across six major items: availability / performance-extensibility / operability-maintainability / migratability / security / system-environment-ecology. It shows otherwise abstract non-functional requirements at concrete levels, preventing perception gaps between users and vendors.
- Non-functional requirements involve tradeoffs. Raising the target uptime raises the cost of redundancy and the like, so weigh the level the business truly needs against the cost to realize it, and agree with users on a level that is neither excessive nor insufficient. Uniformly adopting the highest level as "higher is better" is over-investment, while neglecting it exposes a quality shortfall in operation.
Most-tested: the distinction "business requirement = business purpose", "functional requirement = a function the system provides", "non-functional requirement = quality and constraints such as performance, availability, and security"; "the six items of the non-functional requirement grades (availability / performance-extensibility / operability-maintainability / migratability / security / system-environment-ecology)"; and "non-functional requirements agree with users on the level-vs-cost tradeoff." Watch for confusing "availability and performance are functional requirements" or "non-functional can be left to the vendor."
An e-commerce IT strategist is settling non-functional requirements with the user department for a renewal of the core order system. The business unit strongly requested "a non-stop system that never goes down, 24/7, because we absolutely want to avoid lost opportunities." Rather than fixing the request as the highest-level non-functional requirement as is, the strategist uses the availability item of the non-functional requirement grades to present the target uptime and the allowable planned-downtime and recovery time in stages, laid out against the cost to realize each level (multi-redundant servers, an always-on standby system, site distribution). Realizing non-stop operation (e.g., 99.999% uptime) drastically complicates the configuration and sends costs soaring, whereas in actual operation late-night orders are minimal and a short planned downtime causes almost no lost opportunity. The key point is to choose the level considering the risks on both sides: uniformly adopting the highest level as "higher is better" is over-investment, while neglecting it and setting a low level causes lost opportunity from downtime during busy hours. The strategist agrees with users on the level the business truly needs—say, "keep effectively near-non-stop high availability during the main daytime hours while allowing short planned maintenance late at night (target uptime 99.9%)"—as a concrete grade of the non-functional requirement grades, and chooses a redundancy configuration matching that level. By also securing traceability of which business requirement (avoiding lost opportunity) this availability requirement derives from and which functions/configuration realize it, one can later trace "why this configuration" and withstand requirement changes and audits. Thus, deciding non-functional requirements not by "higher is better" but by making levels visible with the non-functional requirement grades and agreeing with users on the need-versus-cost tradeoff to set them without excess or shortfall is the core of the strategist's judgment.
| Requirement type | Question | Example |
|---|---|---|
| Business requirement | What the business must achieve | Shorten the lead time |
| Functional requirement | What the system does | Register and look up order data |
| Non-functional requirement | At what quality/constraints it is met | Response within 3s, 99.9% uptime |
Trap: "Availability, performance, and response time are part of the functions, so fold them into functional requirements" is wrong—these are non-functional requirements defining the quality and constraints under which functions are met, and burying them in functional requirements blurs the agreement on quality levels and the cost estimate. Also wrong: "availability is better when higher, so uniformly adopt the highest level regardless of cost"—non-functional requirements are a level-vs-cost tradeoff; make the level the business needs visible with the non-functional requirement grades and agree with users to set it without excess or shortfall. Leaving non-functional requirements to the vendor without user agreement is also inappropriate.
5.2.3Section summary
- Separate business requirements (business purpose), functional requirements (system functions), and non-functional requirements (quality/constraints) to clarify rationale and traceability
- Make levels visible in stages via the six items of the non-functional requirement grades (availability / performance-extensibility / operability-maintainability / migratability / security / system-environment-ecology)
- Agree with users on the level-vs-cost tradeoff of non-functional requirements, and bundle stakeholder requirements while preserving traceability
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. For an order-system renewal the business unit demands "a non-stop system that never goes down, 24/7," but raising the availability level raises redundancy costs. Which agreement on the non-functional requirement using the non-functional requirement grades is most appropriate?
Q2. Which classification of the three requirements—"shorten the order-to-shipment lead time," "register and look up order data," and "keep online response within 3 seconds"—into requirement types is most appropriate?
Q3. In requirements definition, conflicting requirements arise from multiple stakeholders, and there is a concern that "what a feature is for" cannot be traced downstream. Which response by the strategist is most appropriate?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.