Note that I understand this is only a persuasive argument and doesn’t give clarity on exactly how we within Insights are planning to do this work with projects (don’t worry, that’s coming), I wanted to start by explaining why we’ve chosen to go about doing FURPS. It’s clear projects and core contributors want clarity, so we’re going to make a helluva effort to provide it. So here goes…
Imagine learning a new language. At first, you fumble with vocabulary, struggle with grammar, and constantly translate in your head. Every conversation is an exercise in concentration and patience. But gradually, something remarkable happens: the language becomes second nature. You find yourself thinking in the new language, expressing ideas naturally, and even dreaming in it. What once felt like a formal, structured process becomes an effortless flow of communication.
This same journey applies to adopting a universal language for software requirements. While the initial learning curve might seem daunting, the end goal is not to create a rigid, formal process, but rather to develop a natural, intuitive way for all stakeholders to understand each other.
The Current Tower of Babel
In the complex landscape of the IFT and its associated projects, we currently find ourselves in a Tower of Babel situation. Each team speaks its own dialect, formed through years of internal practices and traditions:
- Project A discusses requirements in terms of user stories
- Project B focuses on technical specifications
- Project C emphasizes business outcomes
- Project D prioritizes operational metrics
Like travelers in a foreign land trying to order dinner with phrase books and hand gestures, we manage to communicate, but not efficiently or effectively. The result? Misunderstandings, missed expectations, and missed opportunities.
FURPS: A Common Language, Not Just Another Process
The FURPS model isn’t merely a process to be followed—it’s a language to be learned and internalized. Like any language, it provides the building blocks for clear communication:
Functionality: The Verbs of Our Language
Just as verbs describe actions in natural language, functionality requirements describe what the system does. Initially, you might need to consciously think about categorizing features, but eventually, thinking in terms of system behaviors becomes natural.
Usability: The Adjectives of User Experience
These are the descriptive elements that qualify how users interact with the system. Like learning to express emotions in a new language, understanding usability requirements becomes an intuitive way to describe the user’s experience.
Reliability: The Promises We Make
Every language has ways to express commitments and guarantees. In FURPS, reliability requirements become our way of making and understanding promises about system behavior.
Performance: The Metrics of Success
Just as languages have ways to express quantities and qualities, performance requirements give us a vocabulary for describing system capabilities and limitations.
Supportability: The Lifecycle Vocabulary
Like discussing future plans in a new language, supportability requirements help us express how the system will grow and adapt over time.
The Language Learning Journey
Phase 1: The Beginner Stage
- Initially, everyone will need to consciously think about FURPS categories
- Teams might need “translation guides” and reference materials
- Communication might feel slow and deliberate
- Regular practice sessions and workshops help build familiarity
Phase 2: Building Fluency
- Teams start thinking in FURPS naturally
- References become less necessary
- Conversations flow more smoothly
- Requirements discussions become more nuanced
Phase 3: Natural Communication
- FURPS categories become second nature
- Teams naturally organize thoughts in this framework
- Communication becomes effortless
- The formal process fades into the background
Benefits of Language Fluency
When a team becomes fluent in FURPS:
- Requirements discussions flow naturally
- Misunderstandings decrease dramatically
- Project scope becomes clearer
- Resource allocation decisions become more intuitive
- Cross-team collaboration improves
The End Goal: Natural Communication
The ultimate goal isn’t to create another formal process that teams must follow. Instead, we’re developing a shared way of thinking and communicating about requirements that becomes so natural, the formal structure fades into the background. Like a fluent speaker no longer thinks about grammar rules, teams will naturally express and understand requirements in a clear, consistent way.