The Volere Snow Card: A Simple Technique for Better Requirements

Business analysts often face a common challenge when gathering requirements. Stakeholders tend to focus on solutions instead of their actual needs. As a result, important requirements can stay hidden.

At a recent workshop, someone brought up this exact problem. His stakeholders kept talking about solutions instead of the problem they wanted to solve. The conversation soon lost sight of the real needs.

This situation made me think of a technique from the Volere Requirements Process, created by James and Suzanne Robertson, called the Snow Card.

Even though this technique has been around for years, it is still a powerful and practical way to organize requirements discussions.

What Is a Snow Card?

The Snow Card originates from the Volere Requirements Process developed by James and Suzanne Robertson. In Volere, requirements are normally documented in a structured specification template containing fields such as rationale, fit criterion, source, and priority. The Snow Card is a lightweight way of capturing the same information during elicitation workshops before it is transferred into the full Volere specification.

A Snow Card is a small card that captures a single requirement in a systematic format. The core principle is simple: one requirement per card. By writing requirements individually, analysts and stakeholders are able to easily review, move, group, and prioritize them.

The Snow Card covers both what the requirement is and why it is needed, how to test it, and where it comes from.

The name “Snow Card” comes from the idea that many cards can pile up like snowflakes to form a complete layer. Each card is a small part of the puzzle, but together they show the full picture of what stakeholders need.

Snow Cards are simple and low-tech. You can use real cards on a table or digital versions in tools like Miro or Jira. The real benefit comes from how each card organizes the information.

The Structure of a Snow Card

A Snow Card has fields that help turn unclear stakeholder comments into clear requirements. Each field helps make the requirements easier to read and track. Let’s look at these fields one by one.

Requirement ID

This field contains a unique identifier used for traceability.

Requirement Description

The main part of the card is the requirement itself. The description should state what the system must do or what characteristic it must have. It should focus on the needed result, not on a suggested solution.

For example:

“The system shall allow restaurant staff to update menu items quickly.”

Writing a short description captures what stakeholders want. By filling in the other attributes, the stakeholder also has to think about why the requirement is needed and what success looks like, keeping him sharp throughout the definition process.

Rationale

The rationale explains why the requirement is needed. This part is important because it links the requirement to a business goal or stakeholder need. If stakeholders focus on solutions, the rationale helps reveal the real need behind them.

For example:

“Menu changes occur frequently due to ingredient availability. Staff needs to keep the menu up to date to avoid incorrect orders.”

Source

The source shows who asked for the requirement. It could be a person, a group, or even a document. Keeping track of the source helps with traceability and makes follow-up discussions easier.

Typical examples include:

• Restaurant manager • Customer support team • Regulatory authority

In our example, this requirement comes from Jake, who works in the kitchen.

Knowing the source allows analysts to clarify the requirements’ details when necessary and to involve the right stakeholders during needs validation.

Priority

The Volere method sets priorities for requirements by looking at two main factors:

• the level of customer satisfaction if a requirement is successfully implemented, and
• The level of customer dissatisfaction if the requirement is omitted from the final product.

This method is based on Kano analysis, which separates features into three types: excitement features that delight users, one-dimensional features that add value as they are improved, and basic features that users expect and miss if absent. By looking at both the benefits of including a requirement and the problems caused by leaving it out, the Volere method helps teams focus on features that add the most value and make sure basic needs are not missed. This balanced view keeps the process customer-focused.

In our example, Jack from the kitchen staff expects the feature to be implemented. He rates customer satisfaction as 4 if the feature is present. If the feature is missing, he anticipates serious operational problems because staff would have to manually amend menus on paper to indicate available dishes. This could confuse customers and lead to incorrect orders. Therefore, the customer dissatisfaction score is 5. According to the Kano prioritization matrix, the combination of satisfaction 4 and dissatisfaction 5 results in an overall priority of Must-Have.

Fit Criterion

The fit criterion is one of the most important parts of a Volere snow card. It turns vague goals like “easy to use” or “lightweight” into clear, measurable conditions that a solution must meet.

A fit criterion ties each requirement to a clear test. For example, “80% of test users complete the task within two minutes” or “the device weighs no more than 300 grams.” These measures use specific scales like time, weight, error rate, or percentage. The customer or product owner, not the developer, should define them. This keeps the focus on what needs to be achieved, not how to do it.

In our example: “90% of kitchen staff can update a menu item’s availability within 90 seconds without any training or need to consult instructions.”

Fit criteria can show different levels of what is acceptable. There might be a minimum level for a basic feature that must be present, and a higher target for features where better performance adds more value. This way, the fit criterion not only tests a requirement but also links to the satisfaction and dissatisfaction logic behind the snow card’s way of setting priorities.

Supporting Information (Optional Fields)

These fields are commonly present in the full Volere requirements specification template. In quick elicitation workshops, teams often start with a lighter Snow Card that captures only the core fields. As the requirements mature, additional information can be added and transferred into the full Volere documentation.

Here you can download a Volere Snow Card to print it and use it in your workshop:

Download the original template

 

Depending on your project, you can add extra fields to the card, such as:

• Dependencies with other requirements

• Conflicts with other requirements

• Assumptions

• Category

• Supporting Materials

These extra fields help analysts handle complexity as the list of requirements gets longer.

In our case the basic Volere Snow Card can be implemented in MS Excel:

Why the Snow Card Works

The Snow Card technique works because it changes how people talk about requirements. Instead of discussing abstract ideas, stakeholders interact with concrete artifacts. Each requirement becomes visible and easier to examine.

Key benefits include:

• Built-in checklist. The structured fields prompt analysts to think about rationale, fit criteria, source, and conflicts while capturing the requirement, not later during review.
• One requirement per card. This separation makes requirements easier to trace, test, prioritize, and modify without creating confusion elsewhere in the specification.
• Clear ownership. Recording the source or originator provides traceability and makes it easier to revisit or clarify a requirement with the right stakeholder.
• Better prioritization. The satisfaction and dissatisfaction scales support structured prioritization, turning the Snow Card into a decision-making tool rather than just a documentation artifact.
• Early conflict detection. Fields such as conflicts or dependencies help analysts identify contradictions or overlaps between requirements early in the process.

Together, these elements create a shared language between business and technical stakeholders and support more disciplined requirements work.

Applying Snow Cards in Modern Projects

Although the Snow Card technique predates contemporary agile methodologies, its principles retain significant relevance for modern development teams. The technique’s emphasis on clarity, traceability, and stakeholder engagement aligns with the foundational values of agile practice, such as fostering collaboration and adapting to changing requirements. By integrating structured requirement documentation with the iterative and flexible processes found in agile frameworks, teams can enhance their ability to deliver solutions that accurately address user needs. Thus, the continued applicability of Snow Cards highlights how established practices can complement and strengthen current development approaches.

In agile teams, Snow Cards are similar to user stories or backlog items. But the structured fields, especially the rationale and fit criterion, add useful detail and analysis.

Many teams use digital boards where each card stands for a requirement. The main idea stays the same: make every requirement easy to see, organize, and talk about.

A Simple Technique That Still Matters

Requirements engineering often brings in complex models and tools. Still, some of the best techniques are simple.

The Volere Snow Card exemplifies how the foundation of effective requirements engineering lies in disciplined analysis and structured stakeholder dialogue. Its sustained relevance underscores the enduring importance of clarity and collaboration for achieving successful project outcomes.

Sometimes, all you need is a small card and a simple question: What do we really need, and how will we know when we have it?