How to Write Requirements That Don’t Result In Rework

You’re in a sprint demo, three months into an implementation, and the client says: “Wait, that’s not what we meant.”

You pull up the requirements doc, point to the specific line item, and show them they signed off. You’re both right – technically, you built exactly what the requirement said. But what you built isn’t what they wanted. 

Now you’re facing rework, a scope change conversation, and a frustrated client, all because of a bad requirement written too quickly in discovery.

After a decade of consulting and building Salesforce products, I’ve learned that every successful project starts with good requirements. And the problems in nearly every bad project – the kind full of rework, frustration, and timeline and budget problems – can be traced back to bad requirements.

This article explains how to write requirements that are clear, accurate, and comprehensive, and how to build quality checks into your process.

What Defines Bad Requirements?

Bad requirements fall into three categories:

1. Missing: They were never written down at all.
2. Misaligned: Stakeholders don’t agree on what they want.
3. Misunderstood: Stakeholders agree on the written text, but it means something different to each of them.

The foundation for a successful project relies on preventing all three of these. But most teams don’t have a systematic way to assess requirement quality during discovery, so they end up spending way too much time, way too frequently, in frustrating conversations about rework. 

Instead, spending a little more time up front to make requirements high-quality pays dividends later in the project. When requirements are accurate (no misunderstanding), clear (no misalignment), and comprehensive (nothing missing), all stakeholders understand what’s coming next. It means no surprises and no rework.

Specificity and Testability Prevent Misunderstanding

A high-quality requirement is clear: it’s specific and testable.

Specificity Prevents Misunderstanding

When a requirement is specific, there’s no ambiguity about what needs to happen. This seems obvious, but so many requirements look like “The system should make it easy for users to add accounts.”

The more you can eliminate subjective terminology, the better. (What’s “easy”? Who are the users? How should they “add”? Do we care about checking for duplicates?) 

Testability Forces Clarity

When a requirement is testable, it’s possible to prove the requirement was or wasn’t met. Testability is a helpful rubric because when you try to define how you’ll test a requirement, vague language immediately becomes obvious.

For example, “The system should make it easy for users to add accounts” isn’t testable because there’s no way to prove what’s “easy.” The only thing you’re able to prove, in theory, is that at least one type of user can add an account (but in bulk? Via the UI or API? What about permissions?) 

Testability forces you to define:

• Who can take the action.
• How they do it.
• What they’re actually doing.
• What gets validated, and what happens if validation fails.

But one thing to note: it’s easy for specific and testable requirements to sound like solutions rather than problem statements. “Sales reps must be able to create accounts via the New button on the Accounts tab” describes a solution. The underlying problem might be “Sales reps need a fast way to manually key in account information when they’re on calls.” Keep the business problem in mind – that’s what you’re actually solving for.

Writing specific and testable requirements prevents misunderstanding. But that doesn’t help if you never captured the requirement in the first place.

Good Discovery Conversations Prevent Missing Requirements

You might be thinking: Cool, my requirements are specific and testable. But that doesn’t help me if I never captured the requirement in the first place! And if you’re thinking this… you’re correct. 

Missing requirements are a process problem. Making requirements comprehensive requires, basically, having really good discovery conversations and recording them all. 

Setting Up Good Discovery Conversations

The first step is to make sure you’re talking to the right people, in the right environments.

1. Identify Stakeholders. Talk to everyone who will use the system, not just the primary end user or exec sponsor. The people doing the day-to-day work – especially in roles that are ancillary to your primary end user – will throw lots of fun edge cases your way.
2. Structure Your Conversations. Use checklists of common requirement categories (data migration, reporting, integrations, permissions, workflows, etc.) to ensure you’re asking about everything that typically matters. When I do discovery, I tend to get really excited about a specific (usually obscure) topic and go deep – these checklists help bring me back so I can cover all of the important stuff. 
3. Watch People Work. People don’t know how to explain their jobs in the language of the system they’re moving to (that’s your job, as a consultant). And they often don’t think that the little things they do are worth your attention or worth bringing up. These are the ones that bite you! If possible, sit next to your end user for a day and watch them work in the old system. You will find parts of the process they’d never bring up that would otherwise only surface mid-build. As you watch, narrate what you’re observing out loud so it gets captured in the recording – and so your stakeholder can correct you if you make incorrect assumptions.
4. Validate Explicitly. Walk through the requirements doc with stakeholders and explicitly ask: “What are we missing? What haven’t we talked about yet?” 

Running Good Discovery Conversations

When you’re in conversations, the most important thing is to ask the right questions. 

1. “Can you walk me through a specific example?” Understanding the actual way that actual people do their actual processes will be more revealing to you than 100 high-level generic requirements that they give to you. 
2. “What happens when…?” Ask about the exception cases: What happens when this field is blank? What happens when a user doesn’t have permission? What happens when it’s a VIP or a board member?
3. “Who else cares about this?” Requirements that affect multiple teams are where contradictions hide, and it’s better to surface them now than discover them in UAT.
4. “If you had a magic wand and could totally transform this process, what would it look like?” This is my personal favorite. Asking people to imagine what the ideal process would be helps you identify areas of pain that they sometimes assume are just so normal that you can’t fix them. 

Recording and Reviewing Prevents Misalignment

You’ve made your requirements clear by making sure they’re specific and testable. You’ve made them comprehensive through good discovery. 

But there’s one more check: making sure they’re internally consistent. When they’re caught after discovery, contradictory requirements can cause major problems. The way to identify contradictions and potential misalignment is by recording every conversation – and reviewing your requirements carefully.

Contradictions are often not immediately obvious because they live in different parts of your requirements doc, different stakeholder conversations, or different phases of the project. But catching contradictions up front saves so much work later. 

Patterns to watch out for:

1. Timing conflicts: Real-time vs batch, will get you every time.
2. Permission conflicts: One team (usually IT) wants to restrict access that another team requires.
3. Workflow conflicts: It is truly shocking how many companies think their processes in the legacy system are defined, but they have been operating poorly and inconsistently for years.
4. Data conflicts: Especially when it comes to required fields and order of operations.

The best way to catch contradictions is to actively look for them. When you document a requirement, ask yourself:

• Does this conflict with anything we’ve already documented?
• Would this requirement prevent another requirement from working?
• Are we making assumptions that might not hold across all scenarios?

This is also where having requirements traced back to source conversations becomes critical. When you find a contradiction, you need to go back to the stakeholders and say, “In the March 5 call, you said X. In the March 12 email, the finance team said Y. These conflict. Which one is correct?”

Best Practices to Improve Your Processes

Now that you understand what makes requirements accurate, clear, and comprehensive, here’s how to build quality checks into your processes:

1. Record all of your discovery conversations. All those conversations aren’t all that helpful if you don’t record them all – there will be things you miss, asides that take you down a pathway you didn’t expect. It sounds so basic, but record everything.

Then, use an AI tool to extract requirements from those recordings, and compare them with what you’ve written down yourself. Glossa does this really well (full disclosure: it’s my company) – but you can also use NotebookLM, ChatGPT, Claude, etc. 

2. Tie each requirement to its source materials. Traceability is important for each requirement to avoid the rabbit hole of he-said she-said. When you do find requirements that contradict, you’ll need to know where they came from in order to resolve them. For each requirement, note:
   • Which call or document it came from.
   • Which stakeholder(s) provided it.
   • Relevant context from the conversation.
3. Check that all requirements are clear. After you’ve finished discovery conversations and you’re compiling your requirements into a list that you’re going to share with the client, add a step: assess your requirements to make sure they are specific and testable. Go through each requirement and ask:
   • Is there any ambiguous language (like easy, fast, better, user-friendly)?
   • Can I describe how we’d test this?

This will mean you’re sending the best possible requirements to the client, so you’ll be least likely to have to deal with misalignment and misunderstanding – and thus, rework down the line

4. Check that your requirements are comprehensive. Compare your requirements against multiple sources to find missing requirements.
   • Check against discovery recordings: did anything get discussed but not written down? AI is very helpful for this.
   • Use your category checklist: go through the list of common requirement categories and make sure you have requirements for each.
   • Review against current-state documentation: if the client has existing process documentation, user guides, or SOPs, use those to verify what’s in your doc.
5. Check that your requirements are accurate. Group requirements into epics or categories, and review each thoroughly to find potential contradictions. Think about permissions, timing, data requirements, and workflows as common culprits. When you find a contradiction, use the source conversation references to go back to the stakeholders and facilitate a decision, rather than just picking one. 

Is the Work Worth It?

Good requirements are boring. They’re specific, detailed, and sometimes feel pedantic. They take longer to write than vague requirements.

But they’re also the cheapest insurance policy you can buy.

Missing, misaligned, and misunderstood requirements end up being incredibly expensive when they result in rework. They push timelines, make projects go over budget, and cause great frustration, lack of confidence, and trust across the aisle. When you invest in writing good requirements, you save your team and your project headaches, late nights, and stressful conversations. 

But these quality checks do take time. Reviewing hours of discovery calls to catch missing requirements, cross-checking every requirement for contradictions, maintaining traceability for hundreds of line items – it’s all necessary, but it’s a lot of work. 

The solution isn’t to skip the checks – it’s to make them faster. AI tools can help: they can scan call transcripts to extract requirements you might have missed, flag potential contradictions based on keywords and patterns, and automatically link each requirement back to its source conversation. The goal is to make requirements quality checks fast enough that you’ll actually do them. 

Final Thoughts

The teams that consistently deliver on time and on budget aren’t the ones with the best developers. They’re the ones who do the foundational work of getting the requirements right – accurate (preventing misalignment), clear (preventing misunderstanding), and comprehensive (preventing missing) – before anyone creates a custom field.

Requirements are the foundation. Everything else builds on top. If the foundation is shaky, the whole project will be too.

For more Salesforce conversations and industry insights, check out the latest episode of the Picklist podcast below.