From customer needs to implementation:
Building a strong foundation for success
In my previous article, we made an improvement to the Hybrid Model. Now, we’ll take a dive into two of its initial stages: Requirements and Design. These initial phases lay the groundwork upon which successful implementation depends.
Requirement stage
User story—not only a UX thing
Requirements don’t magically appear in a one-hour meeting the day before a project kickoff. If they do, chances are high that the final product will miss the customer’s expectations or cost target. Good requirements must always be derived from real user needs—otherwise, why build it at all? Worse yet, failing to address actual user needs would make the product useless.
However, identifying real needs isn’t always straightforward. It can be a lengthy process, and some stakeholders may resist activities that don’t produce immediate results. Yet, this early-stage effort is crucial.
Take, for example, a statement like:
“As a homeowner, I need my smart thermostat to automatically adjust based on room occupancy, so that I can save energy without manually changing settings.”
or
”As a mechanic, I need real-time diagnostic data from the car’s ECU, so that I can quickly identify and fix engine issues without unnecessary part replacements.”
You get this, the format is “As a [user], I need [feature] so that [goal/problem solved].”
A user doesn’t have to be a person, it can be a system or a component as well, so this applies to the most hard-core Embedded Systems too.
To some, this might seem like a UX exercise—wordplay that UX designers frequently use in their work. Silly you might think—after all, you know the customers and the market very well so the next product just defines itself. Trust me, you might be very wrong. Every time I do this exercise with my customers, the moment of complete silence followed by “oh, we didn’t think about that” occurs, even multiple times. It can turn out to be very costly when this “oh” comes close to the project end, or even worse, never comes at all.
Concept—more than a drawing class
This is my favorite part, hope it will become yours too. Bring your crayons and your creative mind. You start by organizing the user stories. Those that overlap or are closely related might be generalized into a single one. Some have to be split into multiple needs.
Suddenly, a concept starts to take shape. Put it down on a piece of paper or a white board. Discuss with the others, iterate, scrap it if it doesn’t make sense and start over again. Avoid diving into deeply technical discussions. Focus on features, appearance and the user experience with the product. What will all this look like from the user’s perspective. Let it mature and don’t hesitate to repeat the process a few times.
This tends to be a difficult activity for a hardcore developer, and even more so when product owners, UX-designers, architects, project managers and other stakeholders are involved. A true lesson in diplomacy which in reality is an opportunity for common understanding and team spirit for the duration of the project.
Requirement—things are getting formal
This topic itself deserves an article or two on its own, so I will just briefly touch on the key points.
You start by writing high-level product requirements, defining features and properties. No technical details yet—only solutions to the identified needs. Product requirements are typically broken down into system requirements and technical requirements. The exact levels and naming conventions may vary depending on the product and project, but what matters most is that they are well-structured. Technical requirements can be supplemented or replaced with detailed specifications in document form.
To summarize:
Product requirements define the solution to the user’s needs.
System requirements map the solution to the technical side, identifying components, standards, technologies, etc.
Technical requirements specify detailed functions and properties, these are the ones that get implemented.
Although the requirement stage is a stepin the waterfall phase of the project, it doesn’t mean that all requirements are fully defined when transitioning to the next stage. The lower you go in the requirement stack the less requirements are typically defined. Most of the technical requirements or specifications are actually written after the system architecture has been created. This means that the requirement stage focuses more on product definition than on technical implementation.
Design stage
System Architecture—putting the pieces together
Although we may have already touched upon a few system and technical requirements, it is at this stage that we fully step onto technical ground.
System architecture defines the overall structure of a system, detailing how its components interact and function together. It identifies hardware, software, data flow, communication, and key design principles, providing a blueprint for implementation.
System architects, together with senior developers, play a central role in this process. Their focus is on designing a structure that not only meets functional aspects but also ensures scalability, reliability, and maintainability, the whole life-cycle.
Technical requirements and specifications—the devil is in the details
With the system architecture in place, it’s time to revisit the requirement stage.
Technical requirements specify exact behaviors and properties. They cover aspects like data formats, security protocols, hardware tolerances, and performance thresholds.
Unlike high-level requirements, these are highly detailed and often documented formally to remove ambiguity. At this stage, close collaboration between developers, system architects, and engineers is essential to refine and validate these specifications, ensuring they are both realistic and achievable.
Test strategy—design for test
It is also worth mentioning that a test strategy should be initiated at this stage.
A product is not fully developed until it is tested. Testability determines how easily and accurately a product can be verified, making a well-developed test strategy essential. How will individual components be tested, and how will they perform when integrated? Who will conduct the tests, and when? Will specialized equipment be required, and if so, should it be purchased or built? These questions should be addressed as early as possible.
Oh, and don’t forget to design for test. It is far easier to verify a system if it is designed in a modular way, software and hardware components can be probed, and a clear diagnostic mechanisms are in place.
Conclusion
A useful product doesn’t emerge from a single meeting or a vague set of ideas—it is shaped through a process. From identifying real user needs to defining high-level product requirements, breaking them down into system and technical specifications, and ensuring testability. Every stage plays a critical role. The relationship between requirements and design persists to the end of the project.
Skipping or rushing these foundational steps can lead to costly penalty rounds, and ultimately, a product that fails to meet expectations. Taking the time to define clear requirements and a solid architecture from the start will pay off in the long run. A strong foundation not only ensures smoother implementation but also aligns all stakeholders. The result is a successful product, satisfied customers and not the least, happy employees.
