Great questions—let’s break this down step by step, since FURPS+ can feel fuzzy around the edges, especially that "+" section.

First: What is "Operations - system management in its operational setting"? #

Let’s start with the core of FURPS: it covers Functional (what the system does), Usability, Reliability, Performance, and Supportability requirements. The "Operations" entry in the "+" section is all about the hands-on management tasks needed to keep the system running in its production environment—and it’s easy to see why it doesn’t fit neatly into traditional non-functional requirements.

Non-functional requirements describe properties of the system (e.g., "the system must handle 1000 concurrent users" or "downtime must be < 1 hour/month"). Operations, by contrast, refers to actions or capabilities the system must provide to enable maintenance and oversight. Examples include:

• Built-in tools to start/stop individual services or the entire system
• Interfaces to view real-time performance metrics or audit logs
• One-click backup/restore functionality for critical data
• Role-based access controls for administrative staff to manage the system

These aren’t user-facing features, nor are they pure quality attributes—they’re the "behind-the-scenes" operational tools that keep your system usable for the team that runs it. Jacobson included this in the "+" because it’s a critical requirement category that falls outside the core FURPS buckets.

Second: Why does the "+" section vary across sources, and what's its purpose? #

The "+" in FURPS+ is intentionally flexible—this is its superpower, not a flaw. Here’s the context:

• FURPS originated at Boeing as a way to categorize software requirements. Jacobson expanded it to FURPS+ in Applying UML and Patterns to account for project-specific needs that didn’t fit the original five categories.
• Different sources tailor the "+" section to their audience: a cybersecurity guide might add "Security" as a "+" category, an embedded systems textbook might include "Hardware Integration", and a SaaS playbook might add "Multi-tenancy Management".

The "fuzziness" you’re noticing is by design. The "+" isn’t a fixed checklist—it’s an extension point. Its purpose is to ensure teams don’t overlook critical, context-specific requirements that fall outside the core FURPS buckets. For example, if you’re building a government-facing app, your "+" might include "Regulatory Compliance"; if you’re building an IoT system, it might include "Device Provisioning".

Instead of fixating on a "standard" "+" list, use it as a way to capture whatever your project needs that isn’t covered by the core five categories. That flexibility is exactly why it’s stood the test of time.

内容的提问来源于stack exchange，提问作者Mohammad Ali Soleymani