FURPS: Learning a New Language for Software Requirements

Logos
,
1

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.

2 Likes
2

Some questions I haven’t yet figured out:

Milestones

Milestones seems to be a snapshots of a given set of FURPS reaching a stage.

Due to the research nature of our projects, it is unrealistically to expect every FURPS to reach “production” within a 6 months timeframe.

How does one group FURPS? May make sense to have them per domain (reliability vs incentivization vs RLN for Waku) and then define milestones as

  • F1 reaches POC
  • F2 reaches Prod
  • etc

Steps (right to left)

Defining the right-to-left criteria seems difficult. For Waku, it could be purely from a Status integration basis (from PoC outside status codebase to being shipped by default in status app). But this may not be always applicable.

WDYT?

3

Another note. In terms of Ps (and possibly Rs but still need to wrap my head around it).

We are proposing to use this as a driver for Waku to Vac requirements.

For any given P/R item, we would express whether a Tasks is expected from:

  • Waku Research Test (within Waku team): a small scale simulation has run to test the likelihood of P/R to be fulfilled. Might not fully allow to assert completion.
  • Vac/QA: by having a test under unstable network condition that affirms Fs and Rs are as expected
  • Vac/DST: a simulation that assert whether the P is fullfilled.
4

Given the we have a high level roadmap, its possible to carve out scope and as those chunks of scope S1 (or value), the scope could be delivered we group those ‘F-U-R-P-S’ against a tag or milestone(M1); as we progress its possible the next Scope (S2) then we could create ‘additional FURPS’ linked to the M2 milestone. Its important not to lose the ‘high level roadmap’ but would like to see how tags and issue types could help in this.

5

One more comment, in terms of Supportability I am not clear how we track.

For Waku, it could be:

  • mobile/desktop (ie, Status app)
  • Web apps/Browser

For a given set of F/Us. Then having

  • S1: Status app
  • S2: Browser

Would lead to two clearly different streams of work.

If F1 and F2 are done for S1, but nothing is done for S2. Then how does it look like in the final diagram?

Or should all the “S” be set to be feasible together, meaning having a different diagram for status app and browser?

6

I think this goes in the right direction but would need to see an example to wrap my head around it.

Would you be able to produce some simple examples?

7

Im working on concrete examples to pull from.

Also I dont want to be too caught up on the eventual diagrams. The priority is clear definition of work planned. We can build from there.

8

Not too worry about the diagram per se, more about defining F-U-R-P-S and being clear on:

  • what “stage” we commit for each F-U-R-P(-S) within given date (left to right). By stage I mean PoC vs MVP vs private dogfooding etc (let me know if there’s a better word for it @hegaleon
  • How to handle “Supportability” as getting it down for status app vs browser.
9

in broader terms i could propose ‘private testnet’ (Private Dogfooding) and ‘public testnet’ (Public Dogfooding)

10

Where there are different targets with different code bases, then I would target those separately. This makes all things achievable albeit more granular. The most import outcome is the high level narrative is achieved. So applying a SMART Objective approach the target of a milestone “Waku protocol 2.3.1 will deliver optimised message processing to enable a more responsive experience in the 2.3.5 mobile app by Q1 2025”; whilst this is also targeting the Desktop the variable work could merit a different milestone.

1 Like
11

Thanks for that and will try to organize Waku FURPS this way.

12

Continuing a discussion the Waku team was having.

I’m curious if there is any advice for FURPifying privacy requirements that are core to a protocol or product.

Following the guidelines above its unclear how they ought to be captured.

For example specify a private push notification service, what would be the best way to capture the requirements:

  • Users and Applications remain anonymous while using the service
  • Payloads for different recipients shall be indistinguishable from each other.

Most online sources claim that “Security” related features belong in “Functionality”. Is this true for privacy requirements as well?

On the other hand privacy properties are guarantees of the system. In which case “reliability requirements become our way of making and understanding promises about system behavior” is the most applicable.

Any clarity on how to capture these consistently?

(cc: @petty @hegaleon )

13

You, sir, have identified a weakness in the basic FURPS framework. In reality, the standard framework includes a + which includes the things you’ve mentioned as the original intro failed to capture important things like security and privacy requirements.

I didn’t include them because basic technical acumen is important to establish first, then adding nuance is easy.

Id invite you to roughly describe the things you think are important to capture and we can create a + category for them.

14

From what I read, FURPS+ is more about non-software requirements needed to fully deliver a piece of software, such as hardware and devops.

Hence, I am not convinced that using + for privacy and security is appropriate.

I would suggest to follow the recommendation that was referred to: include privacy and security requirements in Functionality.

If we want to make it more explicit, then we could define a new term for this.

On top of my head, we could use “C/Cypherpunk” to refer to the Cypherpunk values we want our software to adhere to.

FCURPS (super easy to pronounce) likely being the best order (Cypherpunk being Functionality for specific properties).

1 Like
15

Here is a proposal on how we intend to use FURPS/Deliverable/Milestone in Waku for 2025 H2, learning from our experience so far: Simplify process by fryorcraken · Pull Request #299 · waku-org/pm · GitHub

16

Id invite you to roughly describe the things you think are important to capture and we can create a + category for them.

As a privacy-centric organization, we design our products with unique requirements around what information is available and to whom. This is what I am trying to capture. Specifically:

  • What information MUST NOT be seen/inferred by the network.
  • What pieces of data MUST NEVER be associated together.

For an “anonymous forum” product, its an important requirement that no one can determine who made a post (aka Message Unlinkability). This is not a generic trait of all forums, but something that is unique to our version of it. It is also not an implicit requirement like “User accounts cannot be hacked” which would be covered by a base level of expectations.

17

as @fryorcraken suggested; I’m happy to list them in the “Functionality” section as that might be the easiest.

However they seem to be a different shape of requirement.

I view Privacy properties as a constraint on the solution space. Similar to Performance and Reliability, the constraint can only be satisfied after the Functionality is complete.

Security tasks on the other hand tend to be additive. e.g. “Users can rotate their IdentityKeys”, “All Payloads are encrypted”. Security is something you can usually add, Privacy is a resultant property of how the features were implemented. As privacy concerns are about the linking of different pieces of data, they tend to be impacted by a wide subset of features.

My question is it ok to have a functionality requirement which is a restriction on how all the other functionalities are implemented? If so, that works for me.

18

I really think we should have a new letter :slight_smile:

I would not use + because it would just be shoe horning our needs with a common practice.

It would make sense for it to be a new letter because we sometimes refer to individual FURPS statement as F1, U3, etc. So while “Privacy” might the better terminology, a second P is not the most practical one.

Maybe we go for A: Anonymity/Privacy. FURPAS

WDYT? cc @chair

19

you can of course, under FURPS+ add those as follows:
+Anonymity (A) - identity of package source obscured? Use of pseudonyms or stealth addresses.
+Privacy(P) - stores to be encrypted, and access consent implemented

  • when we add more, there can be more white space of course, btw technically ‘Anonymity/Privacy’ are F-s but calling those out in + section heightens your Teams focus.
20

It feels to me that the (+) in FURPS+ appropriately captures the attributes for anonymity/privacy that we are discussing.

The “+” was added to acknowledge that there are other important quality attributes beyond these five core categories, such as:

  • Design constraints
  • Implementation requirements
  • Interface requirements
  • Physical requirements
  • Legal/regulatory requirements
  • Cultural considerations
  • Business rules

I favor capturing Privacy/Anonymity specs within the (+) section over adding a new initial to the acronym.