“Requirements aren’t about writing, but about engineering”

Anyone who’s ever been involved in product development knows that misunderstandings in the early stages will cost time and money later on. Yet many projects still struggle to clearly define what needs to be built. Katarzyna Kot, systems engineer and member of the INCOSE Requirements Working Group, sees it happen every day. She has made it her mission to teach professionals how to write and understand requirements more effectively.

“My heart is with product development,” says Katarzyna. “You want to deliver something tangible, but that only works if the foundation is solid. For that, you need clear requirements.”

Katarzyna came to the Netherlands from Poland in 1998 to work at Philips ASA labs in Eindhoven. “I wrote code, designed software, tested products, and became fascinated by what happens before all that.”

Katarzyna Kot, trainer ‘Practical Requirements Writing’

After twelve years at Philips and NXP Semiconductors, she worked as a consultant for clients such as BAE Aerospace and ASML. The process of writing requirements seems straightforward: elicit, analyse, validate, document. In practice, however, it takes a lot of preparation. “People often get stuck wondering what they should actually do.”

The workshop

To help teams put their requirements on paper, Katarzyna developed her first workshops around 2017. What began as tailored in-company sessions has grown into a two-day training course called ‘Practical Requirements Writing‘, now open to a wider audience.

The workshop is intended for anyone involved in requirements, such as product managers, system architects, QA specialists, and domain experts. “We look at the entire product lifecycle,” Katarzyna explains. “In every phase there are different stakeholders and therefore different types of requirements.”

Participants learn how to analyse stakeholder needs, create context diagrams, structure requirements, and assess their quality in terms of completeness, consistency, feasibility, correctness, and verifiability. “We work with real-world cases so participants can apply what they learn immediately. It’s helpful when they bring their own requirements so we can review and improve them together.”

The workshop is particularly useful for professionals with a few years of experience. “They recognize the challenges from practice and immediately consider to handle them better. Once they start asking questions like ‘How do I apply this in my organization?’ or ‘How do I convince my colleagues?’ they are seeing beyond the surface.”

Challenges

Quality requirements can be tricky to define. Vague terms such as robust or user-friendly need to be quantified. “If you say something must be portable, what does that mean? Weight, dimensions? You translate abstract terms into measurable attributes. That’s how quality becomes concrete and testable.”

It’s also important to know when to stop. “Requirements must be appropriate for the level they’re intended for. There should not be too little detail, but don’t over-specify either.”

Participants often become enthusiastic once they understand why requirements are so crucial. “Some people have never had the value properly explained to them. But as soon as they see how the work contributes to the bigger picture, pride kicks in.”

Thinking

Requirements define what must be delivered. They form the foundation for design and testing and even carry contractual value. In industries such as aerospace and semiconductors, having the right requirements is a legal necessity.

Yet many organizations still struggle with them. “People often find it boring or don’t know where to start,” Katarzyna says. “They don’t see the value right away because it’s weeks of thinking without visible output.”

She compares writing requirements to planning a construction project. “Before building starts, you decide where the power outlets go, where the lights hang, and where the kitchen and washing machine connections should be. You document those decisions so the contractor can deliver exactly what you expect. That’s what requirements do, they prevent surprises for both customer and supplier.”

Before you can even write, Katarzyna adds, you must know who the user is, how the product will be used, what the context is and which standards apply. “Those are all engineering skills.”

An important part of the workshop covers templates and writing rules, such as the Easy Approach to Requirements Syntax (EARS). “That helps prevent ambiguity, but it’s not a fill-in-the-blank exercise. You have to understand what you’re writing. A tool can help — but you still have to think.”

Katarzyna also sees potential in artificial intelligence. “AI doesn’t understand context and can’t write requirements, but it can help analyse them — for example, by detecting inconsistencies.”

Her advice for both AI and templates: “Use technology as an assistant, not as a substitute for your own thinking.”

Engineering

What Katarzyna most wants to emphasize: “Requirements aren’t about writing — they’re about engineering.”

She smiles. “A colleague from the U.S. once said that, and I’d love to have it printed on a tile. Because that’s exactly what it is: good specification isn’t administration — it’s designing with words.”

This article is written by Marleen Dolman, freelancer for High Tech Systems.