When designing a system, engineers must first establish customer operational requirements before defining system requirements.

Operational requirements are what the customer wants to do with the system. System requirements are the physical and software functions the system has to perform to satisfy the customer’s operational requirements. They are derived from customer operational requirements.

However, it is a messy world. Customer operational requirements are often vague, ambiguous, and partial. Public speaking skills come in handy when “nailing down” the customer’s operational requirements.

Below are three ways public speaking skills can transform vague operational requirements into something you can actually derive system requirements from:

Ask Structured Clarifying Questions

The most successful engineers ask the best questions. However, they don’t just ask questions—they frame them.

Engineers can publicly model clarity by asking questions like “What does success look like?” “What problem are we solving?”, and “What constraints matter most: cost, speed, accuracy, or risk?”

One of the habits in Stephen Covey’s famous book The Seven Habits of Highly Effective People is to begin with the end in mind. Operational and system requirements should be planned with the end in mind.

What is the end outcome your customer wants to achieve? Often, customers will tell you their solutions rather than the end outcome they desire.

Engineers “walk a tightrope” when discerning customer requirements. Patient dialogue with the customer is key. Determining the customer’s desired outcomes before you start designing the system. This takes patience and time.

The first way public speaking skills can turn vague operational requirements into something you can actually build is by asking structured, clarifying questions.

Another is to reflect and rephrase until everyone agrees.

Reflect and Rephrase Until Everyone Agrees

After hearing a mushy requirement, a strong communicator paraphrases: “What I’m hearing is we want a response time under two seconds for 95% of users, even at peak load—did I get that right?”

This technique exposes hidden assumptions and invites early correction of those assumptions, before design and coding harden them into costly mistakes.

Clarity spoken beats clarity hoped for. This method exposes key metrics that must be met to produce a system that satisfy customer operational requirements.

Using active listening (telling your customer what you think they said and its meaning) is usually a winner if you take it far enough to “nail down” details of what your customer wants—operational requirements.

As you go further along in designing the system to solve your customer’s challenges, it will be harder to change operational and, therefore, system requirements. Time spent defining the correct customer operational requirements upfront is well spent. It will save you and your customer time, money, and conflict.

You will have many discussions with your customer about operational and system requirements. Ensure you document these discussions in detail. This will reduce requirements ambiguity.

Never get into a situation where there are questions you wish you’d asked but no time to ask them.

Two ways public speaking skills turn vague requirements into something you can actually build are by (1) asking structured, clarifying questions, and (2) reflecting and rephrasing the requirements until everyone agrees.

The third way is to use simple stories and examples to test meaning.

Use Simple Stories and Examples to Test Meaning

Engineers can turn abstract requests into short scenarios: “If a customer clicks ‘Submit’ during a surge at noon, what should they see?”

Stories make ambiguity visible. If stakeholders can’t agree on the story, the requirement isn’t ready.

Applying public speaking skills here is about guiding the room through concrete mental pictures, not slides.

I was test director for the U.S. Air Force EF-111A System Improvement Program (SIP) while in the Air Force. The EF-111A was a two-person, standoff electronic warfare jamming version of the F-111A fighter/bomber. We were upgrading the electronic warfare suite with additional memory and upgrading the electronic warfare officer’s (EWO) cockpit display.

We had the users (customers), who were operational EWOs, with us throughout the design of the cockpit display, telling us what was practical and what was not. The many sessions we had were crucial to the operational success of the upgrades.

In addition to system users, every part of the Air Force that would touch the airplane throughout its operational life was also on the design team. These included maintenance, training, and logistics, among other life cycle functions. Again, the design of the upgrades had to work for everyone.

Using operational stories in requirements discussions was crucial to the success of the EF-111A System Improvement Program.

Three ways public speaking skills turn vague requirements into something you can actually build are by (1) asking structured, clarifying questions, (2) reflecting and rephrasing the requirements until everyone agrees, and (3) using simple stories and examples to test meaning.

Public speaking doesn’t make requirements perfect. It makes confusion audible—so it can be fixed before it ships.

Engineers should use public speaking skills the next time they are eliciting customer operational requirements and developing system requirements.

Call to Action

• When you ask your customers about operational requirements, don’t just ask questions—frame them.

• Reflect and rephrase requirements discussions with your customer to expose hidden assumptions and invite early correction of those assumptions, before design and coding harden them into costly mistakes.

• Use simple stories and examples to test the meaning of what your customer is telling you about their operational requirement.

References

• Wiegers, K. & Beatty, J. Software Requirements, 3rd ed., Microsoft Press, 2013.

• Gause, D. & Weinberg, G. Exploring Requirements: Quality Before Design, Dorset House, 1989.

• Heath, C. & Heath, D. Made to Stick, Random House, 2007.

• McConnell, S. Rapid Development, Microsoft Press, 1996.

Being a confident, engaging, and effective STEM speaker is a vital personal and professional asset. With more than 40 years of engineering experience and more than 30 years of award-winning public speaking experience, I can help you reduce your presentation preparatory time by 50%, overcome your fear of public speaking and be completely at ease, deliver your presentations effectively, develop your personal presence with your audience; and apply an innovative way to handle audience questions deftly.

Working closely with you, I provide a customized protocol employing the critical skills and tools you need to create, practice, and deliver excellent STEM speeches and presentations. Let’s connect and explore how I can help you become the exceptional speaker you were meant to be. Please reach out to me at frank@speakleadandsucceed.com or 703-509-4424 for a complimentary consultation. Schedule a meeting with me at calendly.com/frankdibartolomeospeaks