Architecture Process: Getting Requirements from Business
How to Ask the Right Questions—and Get Answers You Can Build On
By now, you should have met your stakeholders and understand what they truly want from you. If you're still unclear, feel free to revisit my previous articles to refresh your understanding.
Now comes the fun part—actually getting started with architecture. If you've picked up any architecture book, it probably begins with something like "gathering requirements." But honestly, what the hell does that really mean? Let's dive in.
First off, let's define what exactly a "requirement" is:
Something you need or want.
Something you must have to achieve something else.
Simple enough, right? Well, not always.
Functional Requirements: What Does This Thing Actually Do?
Functional requirements describe precisely what the system needs to do. Usually, this is the Product Manager's turf. They might provide user stories in Jira or detailed product requirement documents (PRDs). Your role isn't to write these yourself but rather to hold your Product Manager accountable. Review their work. Challenge them.
If you see a PM overcomplicating things, gently reel them back. Ask questions like, "Do we really need this right now? Can we simplify it? What's the MVP?" Emphasize minimalism—less is more.
On the flip side, if your PM is oversimplifying, you must be cautious. A "simple feature" to test a hypothesis can quickly balloon into something production-critical. Suddenly, you've got paying customers and urgent follow-up requests you weren't ready for. This is why negotiating upfront is crucial. It helps to adopt clear release concepts, such as Alpha (no selling), Beta (customer testing), and General Availability (GA, fully sellable). Avoid vague terms like "Proof of Concept" (PoC) or "Minimum Viable Product" (MVP), as these are often misused, leaving you stuck scaling something that's not yet ready.
You can let customers experiment with Alpha or Beta, but hold off on charging them until you're sure you can deliver. In startups, founders will often sell promises before anything is built, but even then, understanding that features need these phases is essential.
Non-Functional Requirements: How Well Does It Do It?
Now, let's talk non-functional requirements—also known as quality attributes or architecture characteristics. These include performance, scalability, availability, and the big one everyone forgets: cost. Technically, modern management books claim that Product Managers should handle these aspects as well, but in reality, most PMs (around 80%) still heavily focus on customers and commercial aspects. And honestly, they probably should.
This is where you, the architect, can really shine.
In my team, we use PRDs that document functional and non-functional requirements. My Product Managers and I collaborate on these, sometimes in real-time, sometimes asynchronously. While the PMs usually provide functional specs, I drive the non-functional aspects by asking questions from the customer's perspective:
What's an acceptable response time?
Is a 2-second latency fine for real-time analytics dashboards?
Does historical data need to be refreshed every 4 hours, or can we stretch it out further?
Also, never overlook cost. It's tempting to push cost discussions aside and "focus on delivering value faster." But trust me, ignoring cost early usually leads to painful regrets. Cost often highlights architectural mistakes quickly, guiding better decision-making upfront.
Here's a quick story: Imagine you're building a new feature and anticipate heavy database usage down the road. Initially, AWS DynamoDB seems ideal—easy setup, pay-as-you-go, zero upfront hassle. But surprise! There's no simple path to migrate from DynamoDB to a more cost-effective self-hosted alternative later. Switching becomes a massive project, involving the rewriting of code and the migration of data.
Instead, starting with something like Aurora and moving to RDS later, or DocumentDB shifting to Atlas Mongo, makes your future self a lot happier.
However, you'll only know the best path if you constantly engage with the Product, ask the right questions, and clearly interpret the answers into solid, non-functional requirements. Think of yourself as preparing the house before the storm hits, rather than reacting afterward.
The Unspoken Requirements: Reading Between the Lines
Finally, there are requirements no one explicitly tells you about, but they're crucially important. This is why I love company town halls and OKRs. They're fantastic for understanding what business leaders actually aim for—and translating their visions into system improvements.
Picture this: Your CEO announces, "We're going to double revenue in two years!" Sounds exciting, right? But as an architect, your immediate thought should be "How?"
There are only a few ways this can happen:
Scaling existing features: More salespeople, selling the same stuff, meaning your current system must scale up.
Adding new features to upsell: Slower user growth for existing features, but broader scaling is required for new ones.
Expanding into new markets: Rapid user growth for both existing and new functionalities, requiring broader and deeper scaling.
The tricky part? Product often obsesses over new features, neglecting the scalability of existing ones. Your job is to ask hard questions, uncovering the path your company intends to follow. Then, enlighten Product Managers about the realities and necessities involved.
In my experience, waiting for "them" to think proactively rarely works. So, don't hesitate—ask "them" yourself.
That's it for today. In the following article, we'll explore other requirements sources lurking in the background.
Want to learn more?
🎓 Check out the course: Modeling, Viewpoints, C4
🌐 Follow us on LinkedIn: Software Architecture Guild
📖 Explore the Free Guide: Jump to Website