Finding the right words at critical moments can be challenging enough, but capturing and expressing your client’s needs? That’s a whole new level. Welcome to the needs and wants meeting, where the magic word is: requirements.

In the software development world, “requirements” is a top-tier term. It easily ranks high in the Software Development Glossary, possibly right after the well-known  Software Development Lifecycle. Why this topic? Because we take them seriously and we enjoy those meetings where versatility is mandatory. The Product Manager’s role is to understand every articulated need and uncover those that aren’t. But the complexity of requirements is just the beginning. Do they control our scope? Do they influence our design? Who really knows all that? And how can you know all that? The puzzle doesn’t end there. Requirements come in various forms, and they can change at any moment!

So, let’s start from somewhere.

Decoding the core - understanding requirements

Requirements are the heart and soul of any project in the software development world. Imagine trying to build a house without knowing if the client wants a cozy cottage or a sprawling mansion. Requirements are the detailed description of our client’s needs, defining the product’s purpose and how it should function.

But how does a Software Product Manager identify these needs? If a requirement is essential for the core functionality of a product, it’s a “Must” – these are the needs. Features that add value but aren’t crucial? Those are the wants.

Turning wants and needs into actionable requirements could be the beginning of a successfuly project story.

Our Needs and Wants meeting are the key. Requirement sessions are crucial because they’re not just about listing features – they’re about truly understanding the client’s vision and goals. The Software Product Manager (SPM) dives deep, eliciting these requirements through dynamic discussions with the client and expert advisors.

Why is this meeting so crucial? Because it’s not a one-and-done deal. Requirements evolve, priorities shift, and new ideas emerge. These meetings often span several weeks, ensuring that we capture every detail and adapt to changes smoothly.

So, here, at Mileva, our goal is always to build the right product for our client. Through these collaborative sessions, we ensure that we’re not just meeting expectations but exceeding them, turning visions into reality.

Requirements activities

Now, let’s make something clear - requirements don’t just appear out of nowhere. They go through several crucial phases:

• Eliciting requirements;
• Expressing requirements;
• Prioritizing requirements;
• Analyzing requirements;
• Managing requirements.

So, as you can see, these activities transition from an investigative process, through framing and prioritizing, to analyzing and finally organizing them. Unlike the commonly used term "gathering," which implies passively collecting information, requirements need to be actively elicited through an interactive process between the client and the Product Manager. Now you know that we emphasize the importance of collaboration over simple extraction.

Let’s see how we do that – we'll tell you a short story.

One of our recent clients emphasized the need for their service’s image to always be in front of the customer on the app we were developing. Our solution was to keep the image visible as the customer scrolls. The outcome was a single page where the service image and information were prominently displayed, making the purchase more accessible.

We almost forgot! Documenting these requirements is a critical step. The Software Product Manager typically writes product requirements in various formats such as Product Requirement Documents (PRDs) or wireframes, with user stories being the most “developer-friendly". Eventually, these user stories are refined through technical reviews and a risk plan is generated in discussion with the development team.

Types of requirements

In the world of software development, everything comes in multiples, and requirements are no exception. Understanding the different types of requirements is crucial for Project Managers, as they need to categorize and address each type effectively.

Here’s a closer look at the various types of requirements you might encounter:

1. Business Requirements: high-level business needs and objectives that the project aims to achieve;
2. User Requirements: describe what the end-users expect from the system (known to us as user stories or use cases);
3. Functional Requirements: describe the interactions between the system and its environment, detailing what the system should do;
4. Non-functional Requirements: define the operational qualities and constraints of the system, such as performance, usability, reliability, and security;
5. Domain Requirements: specific to the industry or domain for which the software is being developed (terminology, regulations, and other specific needs);
6. External Interface Requirements: define how the system will interact with other systems, hardware, or software;
7. Physical Product Settings: include the physical and environmental conditions under which the system will operate;
8. Development Constraints: limitations or restrictions on the development process, such as technological, budgetary, or time constraints.

Understanding and managing these various types of requirements is key to creating a successful software product that not only meets the client’s needs but also operates smoothly and efficiently within its intended environment.

Avoiding requirement missteps

Getting clear on what the client truly needs is often the trickiest part of writing good requirements. People usually describe what they want, not why they want it. That’s why your job isn’t just to listen, it’s to interpret. Asking the right follow-up questions (“Why now?” “What happens if we don’t build this?”) is often what separates clear direction from confusion down the line.

Assumptions are your biggest enemy here. If you document requirements based purely on what's been said, without digging deeper, you risk building features no one uses, or solving the wrong problem entirely. A solid PRD should help you avoid the “solution trap.” It should describe problems clearly before suggesting how to solve them. This helps everyone, from design to engineering, focus on what actually delivers value.

In short: be a translator, not just a note-taker. Every requirement should carry both a purpose and a problem behind it. If it doesn’t, challenge it.

Verification vs. Validation: getting it right from the start

Once your requirements are defined, the next challenge is making sure they actually lead to the right product. That’s where verification and validation come in.

• Verification asks: Did we build the product correctly, according to the documented requirements?
• Validation asks: Did we build the right product—the one our users actually need?‍

This mindset is central in frameworks like the V-model, where each phase of development is paired with a corresponding phase of testing. When done right, your requirements don’t just guide development—they also become your criteria for success.

Final thoughts

Having a clear vision for your project helps you stay on top of the ever-evolving changes. Your developers, clients, and partners need to know exactly what’s expected to achieve their goals smoothly.

This is where our Software Product Manager steps in! We'd guide you through the entire process, acting as the crucial link between your ideas and the developers' actions. Achieving clarity is essential for any organization’s success because nothing gets done unless everyone is on the same page from the start, right?

It’s important to remember that the requirements phase isn’t just a one-time event. Requirements are continually refined throughout the software development lifecycle. Navigating the sea of requirements can be tricky, with plenty of potential traps along the way.

Want to know how we avoid these pitfalls? Stay tuned for our upcoming posts where we'll dive deeper into our strategies and insights!

References & inspiration

• Karl E. Wiegers, Joy Beatty - Software Requirements (3rd Edition) ‍
• Project Management Institute (PMI) - A Guide to the Project Management Body of Knowledge (PMBOK Guide) ‍
• IEEE Std 830-1998 - IEEE Recommended Practice for Software Requirements Specifications ‍
• https://cs.uwaterloo.ca/~dberry/FTP_SITE/students.theses/TjongThesis.pdf