Specification is the process of representing business or customer needs in a form that is clear, precise, and actionable for diverse audiences, from developers and testers to business stakeholders.

An appropriate and complete requirements specification does nothing to ensure a successful implementation; however, it makes it possible. – Kulak & Guiney

That’s the heart of it – specifications have no inherent value. Their worth lies in how effectively they enable others to understand, design, build, test, and deliver solutions that meet real needs.

A good specification doesn’t replace conversation; it recaps it. It’s not the start of communication, but the artifact that reflects the shared understanding reached through elicitation, analysis, and eventually, validation. It’s how we codify what we’ve agreed upon in a way that provides for traceability and consistency throughout the solution delivery process.

Best practices for effective specification:

• Tailor to your audience. Developers, testers, and sponsors each need information framed in their way. Write your specifications with their needs in mind.
• Be concise, not cryptic. Brevity with clarity beats exhaustive detail that no one uses.
• Visualize whenever possible. Diagrams, mockups, and flow diagrams communicate more than text alone and bring precision to combat the ambiguity of natural language.
• Connect to outcomes. Trace specs to the goals they support and the success criteria they serve.

The goal isn’t to create deliverables. It’s to create alignment and to enable action.

See other posts in the EASVM series:

• Elicitation
• Analysis
• Validation
• Management

Management refers to the ongoing coordination, traceability, and adaptation of requirements throughout the solution lifecycle. It’s how we maintain continuity and alignment, even as goals, constraints, and decisions evolve.

“You can’t control the wind, but you can adjust the sails.” – Unknown

Requirements aren’t static assets. They’re living commitments. Managing them well ensures that the intent captured early remains intact after contact with delivery, change, and real-world complexity.

Think of requirements management like gardening: You don’t just plant once and walk away. You prune, water, and adapt to the environment to make sure what you’re growing is healthy and still worth harvesting.

Best practices for effective requirements management:

• Establish traceability. Link requirements to goals, design decisions, and tests.
• Monitor change proactively. Ensure updates ripple with awareness and intent.
• Continuously prioritize. As context changes, so may the priority and focus.
• Communicate impact. Surface the effects of changes before they become issues.
• Right-size the rigor. Govern just enough to protect value, without bogging down momentum.

Requirements evolve. Management is how we evolve with them, without losing our way.

Wrapping Up the EASVM Series

EASVM is only a framework, but with effort it can develop into a mindset for delivering clarity, alignment, and confidence at every step of solution definition.

• Elicitation starts the journey with curiosity and conversation.
• Analysis brings meaning and structure to complexity.
• Specification captures shared understanding in forms we can act on.
• Validation ensures we’re aligned before we invest.
• Management keeps it all connected, current, and on course.

Together, these disciplines create the conditions for success, not just in delivery, but in stakeholder engagement, strategic alignment, and meaningful results.

Thanks for following along! I hope this series has sparked ideas, clarified concepts, or simply reminded you of the importance of solution definition.

Let’s keep the conversation going!

Validation is the practice of confirming that documented requirements accurately reflect stakeholder intent, align with business needs, and are feasible for delivery.

“We accomplish what we understand. If we are to accomplish something together, we need to understand it together.” – attributed to Ron Jeffries

Here’s the thing: validation shouldn’t be a heavy lift. If we’ve done elicitation, analysis, and specification collaboratively, stakeholders won’t be seeing the requirements for the first time; they’ll be recognizing what we’ve already discussed, clarified, and agreed to.

At that point, validation becomes a confirmation, not an investigation.

It’s also an opportunity to improve. Constructive feedback in validation doesn’t mean we failed; it means we’re learning, refining, and getting closer to delivering something useful and valuable that will enable our counterparts to design, build, and test the resulting solution.

Best practices for effective validation:

• Engage the right people. Validate with users, implementers, and decision-makers – not just approvers.
• Use real scenarios. Walk through examples or simulate usage to expose gaps and assumptions.
• Keep it conversational. Validation works best when it feels like a working session, not a formal audit.
• Focus on outcomes. Validate not just the content, but its alignment to the defined success criteria.
• Welcome rework… early. A revision in validation is many times cheaper than a redesign after deployment.

Validation is a checkpoint, not a choke point – when we build understanding as we go.

See other posts in the EASVM series:

• Elicitation
• Analysis
• Specification
• Management

Analysis is the process of examining inputs: needs, data, conversations, constraints, and transforming them into meaningful, actionable insights. It’s how we uncover patterns, evaluate options, and connect the dots across domains.

In solution definition and delivery, this is where understanding becomes structure, and where misalignment is exposed before the cost to fix it grows exponentially.

Best practices for effective analysis:

• Ask “why?” and “so what?” Go beyond the stated need to understand its drivers and implications.
• Use models to think. Flows, maps, and diagrams aren’t just communication tools; they’re thinking tools.
• Balance detail with relevance. Zoom in where it matters, zoom out to see the whole.
• Engage others in sense-making. Analysis is strongest when it’s collaborative, not solitary.
• Trace decisions to outcomes. Link requirements to business goals to maintain focus and value alignment.

“The perfect is the enemy of the good.” – Voltaire (attributed)

But beware—analysis isn’t about perfection, it’s about momentum. Think of analysis as sharpening a blade: It needs to be sharp enough to cut cleanly, but if you keep honing forever, you never get to the cut.

A good analyst doesn’t just capture complexity; they clarify it. The goal isn’t more information. It’s better decisions.

See other posts in the EASVM series:

• Elicitation
• Specification
• Validation
• Management

I learned about EASVM in a requirements training I did early in my career, and it has stuck with me since. Who does each element, how long they take, and what we call the outputs vary depending on delivery methods and other factors. But to create quality requirements or to perform discovery well, we’ll want to address them all. Too often, we focus on one part (usually documentation) and downplay the rest.

EASVM. Each element plays a distinct role:

• Elicitation brings needs to light.
• Analysis gives them shape.
• Specification makes them actionable.
• Validation ensures we’re aligned.
• Management keeps it all on track.

Let’s talk a little about each element, what it includes, and why it is important, beginning with Elicitation.

Elicitation

“The biggest problem with communication is the illusion that it has been accomplished.” – George Bernard Shaw

So many delivery issues trace back to this illusion.

Elicitation is the intentional act of discovering, uncovering, and clarifying information through structured interaction. It’s not just about asking questions – it’s about making meaning visible.

In solution discovery and definition, elicitation is the foundation of shared understanding. It ensures we uncover not just what stakeholders say they need, but what they mean, what they value, and what they may not have thought to express.

Here are a few best practices for effective elicitation:

• Set the stage. Build trust and context before jumping into techniques. A stakeholder who feels heard will be more forthcoming.
• Diversify your methods. Don’t rely solely on interviews. Observation, workshops, prototypes, and surveys each reveal different layers of insight.
• Listen between the lines. Pay attention to what’s not said, and follow up on inconsistencies or assumptions.
• Visualize early. A sketch on a whiteboard often reveals more than an hour of discussion.
• Iterate often. Revisit and refine as understanding deepens – early alignment prevents downstream confusion.

The goal of elicitation isn’t documentation – it’s clarity. Because communication isn’t complete until understanding is mutual.

If communication is the currency of collaboration, elicitation is how we keep it honest.

In the related posts linked below, I break down the remaining elements: Analysis, Specification, Validation and Management. For each, we explore what it looks like in practice, why it matters, and how it contributes to shared understanding and better outcomes.

• Analysis
• Specification
• Validation
• Management

Let’s demystify the real work of discovery – one step at a time!

A: How long is a story point in real time?
B: How many did you do in your last sprint?
A: 23
B: Then, for you, it’s a 23rd of a sprint
A: But the time before that it was 19
B: Then for you at the time it was 1/19th of a sprint.
A: But how long is it really?
B: We answered that.

— Tim Ottinger (@tottinge) July 6, 2018

Here are a couple tweets from @GoldrattBooks, an interesting follow for insights on operations, DevOps and process improvement.

DevOps explained using ToC Logical Thinking Process https://t.co/BCdDUDb5Db @kesor6 #DevOps #tocot pic.twitter.com/Wh7R2NNicv

— Goldratt Books (@GoldrattBooks) July 11, 2018

“Features have no value until they are in the hands of a user and being used for a productive effort. So any activity not spent getting the next most valuable feature into the hands of a user quickly is just waste.” https://t.co/49fzipMGTZ #tocot pic.twitter.com/4r0t7UrEUN

— Goldratt Books (@GoldrattBooks) July 11, 2018

No digest is complete without some words to live by…

pic.twitter.com/EJOSOizFd9

— Wisdom to Live (@wisdomtolive) July 4, 2018

The topic of our conversation was the “essence” or underlying “why” of business analysis, and how focusing on that “essence” or “why” can benefit the individual analyst, and the organization as a whole.

At the end of the podcast, Dave also mentioned I’ll be speaking at this years Building Business Capability conference in Las Vegas. If you’d like to join me there, use my speaker discount to get 10% off the registration cost. Just enter the code “SPKLVJBAB” when prompted to get the discount.

If you’d like to listen to the interview, here are a few ways you can access it. I’d be interested in your thoughts and feedback!

Mastering Business Analysis website: http://masteringbusinessanalysis.com/episode71

iTunes: https://itunes.apple.com/us/podcast/mba071-essence-business-analysis/id961865564?i=1000368375970&mt=2

Stitcher Radio: http://www.stitcher.com/s?eid=44220947

These models and visuals can and should be used as tools for eliciting requirements and driving to shared understanding; as ways to facilitate working discussions on topics for which we are seeking clarity. Start simple, start messy. Use the process as one of “collaborative creation”. When we draw on the whiteboard together – or model a process flow together – all parties walk away with the dialog and context for how we arrived at the end image. If we don’t see things the same way at first, we draw and discuss and deliberate until we achieve that elusive shared understanding.

The tacit knowledge – or knowledge that comes out in the dialog and sketching, but isn’t captured in the final documentation – is often a critical gap or missing link between business analyst and stakeholder that limits the success of our efforts.

I’ve found that the process of deliberating and rationalizing potential paths together with business and delivery stakeholders until we reach an agreed upon “best way forward” provides the real value in visual modeling.

“The chief virtue that language can have is clearness, and nothing detracts from it so much as the use of unfamiliar words.” – Hippocrates

Apparently, even back in Hippocrates’ day (approximately 450 BC), business professionals had a tendency to confuse their stakeholders with acronyms, jargon, and odd colloquialisms. In business communication, first and foremost in importance is achieving mutual understanding. Some may be able to follow jargon or sophisticated phraseology, but one stands a far better chance of ensuring understanding with clear, simple, common language. Some things never change!

Think of a book you’ve read and enjoyed which was later interpreted as a movie. With the book, your interpretation of the appearance of the settings and characters is a product your imagination, which is shaped by your unique life experience. Every reader of that book comes away with a somewhat similar, but different perspective.

An author can narrow down some of the variance in interpretations by adding more descriptive detail. Think of a book you’ve enjoyed for its vivid descriptions of setting and depth of character development. This can be great for a riveting novel that we wish would never end.

Perhaps, upon leaving the movie based on a book you’ve read, you considered (or commiserated over) how different the characters and the scene were from how you’d imagined them. Your interpretation of the words in the book is as valid as anyone’s. It just didn’t match those of the producer of the film, and possibly, the author of the book. This makes for interesting discussion and critique.

In the book’s cinematic version, with the addition of the audio and visual elements, all viewers come away with a shared mental image of the appearance of the settings and characters, because the additional sensory dimensions make them more explicit. Similarly, visuals, such as pictures, diagrams or other types of models can be helpful in our business communication because they eliminate much of the “imagination,” or ambiguity of words, making meaning more explicit. Visuals serve to calibrate the natural differences in our mental images.

Now, unlike that great book or movie, most of us don’t read business documents such as  a requirements specification for enjoyment. And unlike the book, there can be significant repercussions when one reader’s interpretation of the content varies widely from another’s. The Big Thick Document (BTD) is a product of the notion that increasing a document’s length to add more detail will improve the communication value of the document. Unfortunately, the opposite is more often the result because the longer document is, the:

1. Less likely to be read
2. Less likely to be understood if it is read
3. More likely errors or omissions are to be overlooked, as readers tend mistake length and detail for precision and accuracy.

Thoughtful use of visuals – even, and especially in rough or early drafts – adds a dimension of “understandability” to the ideas expressed in documentation that is not possible in a mostly text-based format, and at very little additional cost. In fact, often it is more work manipulating language to describe something than it is to represent it visually. To this end, a white board or a blank sheet of paper and a drawing utensil are valuable tools when it comes to working through ideas to establish common understanding.

A few questions we may ask to help us optimize our efforts:

• What can we give business stakeholders who want to confirm for us that we’re on the right path that isn’t overwhelmingly long and difficult to decipher?
• What can we give delivery team members that, first, summarizes the details and provides context, then, expresses the details in as easy a form as possible to understand and use to do their work?
• How can we strike an acceptable cost/benefit balance in doing these things?

Featured image by Bartosch Salmanski