Software Architecture Guild

Software Architecture Guild

Architecture Process: Getting Requirements from Business

How to Ask the Right Questions—and Get Answers You Can Build On

Ilya Hardzeenka's avatar
Ilya Hardzeenka
Jul 21, 2025
∙ Paid
Create meme "I need your clothes, terminator I need your clothes, pictures  terminator 2 I need your clothes" - Pictures - Meme-arsenal.com

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.

Architecture Process: Who Is the Stakeholder and How to Find One

Architecture Process: Who Is the Stakeholder and How to Find One

Ilya Hardzeenka
·
July 14, 2025
Read full story
Architecture Process: What Those Business Guys Want from Us, Technical People

Architecture Process: What Those Business Guys Want from Us, Technical People

Ilya Hardzeenka
·
July 16, 2025
Read full story

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.


Want to learn more?

Check out the Courses, Follow us on LinkedIn, and Explore the Guide


User's avatar

Continue reading this post for free, courtesy of Software Architecture Guild.

Or purchase a paid subscription.
© 2026 Software Architecture Guild · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture