Requirements Management in Software Development
Carlos:
I’m Carlos Almeida, Engineering VP at SPK and Associates.
I have years and years of experience with very large projects in software development and infrastructure, DevOps, regulated and unregulated industries. I love to talk about this topic — it’s near and dear to me.
Michael:
Yeah, I immediately thought of you when we talked about this topic, Carlos. You have some really good experience here — and when I say experience, I mean you’ve experienced pain.
So, let’s start with that pain. Why do you think so many software projects struggle due to poor requirements, and what are the key characteristics of well-written requirements?
Why Software Developers Struggle with Requirements
Carlos:
It’s interesting — when you look at why so many software projects run into trouble, not just software but hardware too, it often comes back to requirements — or the lack of them.
A lot of the time, they’re either vague, incomplete, or written in a way that means different things to different people. And when you start a project on that kind of shaky foundation, you end up with missed expectations, endless rework, and frustrated teams.
Part of the problem is that writing good requirements is hard. It’s both an art and a science. You need to understand the business context, user needs, and technical constraints — then express those in a way that’s unambiguous and testable.
That’s not a skill set most organizations formally train people in.
Key Characteristics of Good Requirements
For me, the best requirements always share a few key characteristics:
1. Clarity – Everyone, from the developer to the tester to the business stakeholder, should read and interpret it the same way.
2. Traceability – You can connect each requirement back to a business objective or regulatory need. Nothing should exist “just because we felt like it.”
3. Testability – You should be able to measure whether a requirement has been met or not.
4. Prioritization – Not all requirements are created equal. Knowing which ones are critical versus “nice to have” is vital.
When teams get these fundamentals right, everything else downstream — design, testing, compliance — becomes much smoother.
It’s like building a house: if you invest the time in getting the blueprint right, you don’t have to keep knocking down walls later.
Michael:
Yeah, definitely don’t want to knock down walls — that’s a bad start to building a house!
Best Practices for Gathering and Documenting Requirements
Given those attributes, Carlos, can you walk us through some best practices for gathering and documenting requirements, especially in cross-functional or highly regulated environments?
Carlos:
Absolutely. Gathering and documenting requirements is really more like a team sport, especially in regulated environments like medical devices or aerospace.
You’ve got engineering, QA, regulatory, and marketing — they’re often all sitting at the same table.
One of the best practices I’ve seen is to start with structured conversations instead of jumping straight into documentation. Things like workshops, user story mapping, or even a simple day-in-the-life walkthrough can help uncover what people really need versus what they assume they need.
The second thing is using a shared language. In regulated industries, engineers might say one thing, regulatory teams another, and business folks something else. If you don’t normalize that language, you end up with conflicting interpretations.
That’s why frameworks that use use cases, user stories, or models are so powerful — they give a common way to express requirements.
Then comes the documentation discipline. It’s not just about writing things down — there’s a structured way to write requirements so they’re clear.
How to Write Strong, Testable Requirements
A well-written requirement usually follows a simple structure — the classic “The system shall…” pattern.
This forces you to be specific, measurable, and unambiguous.
A solid requirement has three parts:
1. Subject – Who or what is performing the action (usually “the system”).
2. Action – The “shall” part, such as shall record, shall display, shall calculate. The word “shall” makes it mandatory, not optional.
3. Object or Condition – What the system is acting upon, or the condition being met.
Example:
The system shall record the user’s temperature in Celsius within two decimal places.
That’s clear and specific.
Weak requirements leave those things out, like:
The system shall be user-friendly.
What does that mean? You can’t test it.
A stronger version would be:
The system shall allow a new user to complete registration in less than three minutes without assistance.
That’s measurable and testable.
Michael:
I love that. Breaking down the complexity is part of the game when writing requirements.
The Importance of Early Validation in Requirements Management
I want to twist it a little bit — how can testing early help reduce rework and keep projects on track and within budget?
Carlos:
Early validation is huge. It’s probably the single biggest thing you can do to reduce rework and keep a project on schedule.
The earlier you catch a misunderstanding, the cheaper it is to fix. I use this model with software bugs:
-
Catch it in development → cheap.
-
Catch it in QA → more expensive.
-
Customer catches it after release → really expensive.
The same logic applies to requirements. Spend more time in workshops and team meetings refining them so ambiguity doesn’t slip through QA or reach your customer.
Early validation creates quick feedback loops before you’ve invested too much time or money building the wrong thing.
That could mean:
-
Reviewing prototypes with end users,
-
Walking regulators through your traceability matrix, or
-
Simply reading requirements back to stakeholders and asking, “Is this what you meant?”
In regulated environments, early validation isn’t just a nice-to-have — it’s proof. It shows auditors and oversight bodies that you verified alignment at each stage.
For me, early validation is about three things:
1. Protecting the budget
2. Protecting the schedule
3. Building trust — between business and engineering teams, and with external stakeholders.
When you get that right, the whole project just moves more smoothly.
Michael:
100%. Couldn’t agree more. I love that, Carlos.
Ensuring Clear Requirements During Software Development
Thank you for sharing your knowledge and experience on getting better, clearer requirements.
If you found this information useful, please like and subscribe to the SPK and Associates YouTube channel, where we share decades of product and software experience.
Thank you, Carlos — back at you, and we’ll see you guys next time.
Carlos:
Thanks!
