The classic requirements specification is often considered an indispensable starting point for an electronics project. However, in reality, this approach often proves to be inflexible. Requirements are still unclear, the application is complex, and the optimal technical solution has not yet been determined.
At PICKPLACE, we therefore take a different approach: We start with dialogue – and together with the client, we develop a well-founded yet adaptable technical foundation. The goal is to formulate customer ideas that we ultimately implement into electronic products.
Structured Introduction to Embedded Systems Development
Many of our clients have a concrete idea or technical goal, but not yet a detailed requirements specification. This is not a hurdle for us – on the contrary: the best solutions often arise in conversation. Early exchange makes it possible to narrow down goals, examine technical possibilities, and set up the project correctly from the start.
Instead of demanding a complete requirements specification, we'll start with a technical discussion. In it, we'll clarify the context, environment, functional requirements, and important constraints. From this basis, we'll develop an initial rough concept, which will later be refined through documents and technical specifications.
Iterative refinement instead of rigid planning
The advantage of this approach: It leaves room for further development. Requirements can be adapted during the project without blocking the entire process. Through regular technical reviews, we ensure that we always stay close to the customer's actual needs – and that these are also documented.
So, we don't work without documentation, but rather use it intentionally: for alignment, for validation, and for a safeguard for both sides. This results in a technical specification that is not based on assumptions, but on a mutually developed understanding.
As a development and manufacturing partner, we consider the entire product realization as a single unit. As early as the concept phase, we pay attention to aspects such as component availability, thermal feasibility, and testability. The goal is clear: the solution must not only function technically but also be economically viable for mass production.
This mindset – Design for Manufacturing – is incorporated into every step of our development process. Because we manufacture ourselves, we know the typical hurdles and can avoid them from the very beginning.
Documentation in the electronics development project
Naturally, a project ultimately needs a clear description of requirements and scope. However, for us, this doesn't arise speculatively but emerges from the process. As soon as technical questions are clarified, we create a structured proposal with the agreed-upon specifications. This documentation is not only clearly worded but also technically sound and aligned with the actual implementation.
The graphic shown below illustrates our typical development process in two variants: the top shows a classic linear approach starting with a requirements specification, and the bottom shows our iterative, dialogue-based approach.
In the classic model, the project begins with a complete catalog of requirements. All specifications must be finalized in advance before development can even start. This linear approach initially appears orderly but carries high risks: if something is overlooked, later correction is complex or expensive. Adjustments are often not planned for. Our model therefore starts earlier: instead of fully specifying the device from beginning to end at the start of the project, we begin with the specification of joint collaboration. The boundaries and handovers are defined, as well as the expectations of both parties for the project.
Only in the following steps will the concrete solution be developed together with the customer from this set of requirements. Technical reviews with the customer will take place between each phase – specification, architecture, design, commissioning. These feedback loops are the crucial difference: they not only enable transparency and co-creation, but also lead to a better technical result.
Instead of writing a single final document, multiple coordinated intermediate stages are created throughout the process. This ensures that requirements and implementation are always aligned. The coordination steps are documented and continuously developed – together, step by step.
The aforementioned graphic explicitly names the accompanying documents and test objects in our process:
- PROJECT REQUIREMENTSThe jointly developed functional and non-functional requirements for the product.
- DOCUMENT PLANA structured overview of the technical and organizational documents to be produced in the project.
- DEFINITION OF DONEA binding definition of when a development step is considered complete, including criteria for technical functionality, documentation, and review approval.
- PROJECT REVIEWThe planned time for overall acceptance or strategic course correction during the project.
In parallel, distinctions are made in terms of content between the hardware and software paths:
- HARDWARE REQUIREMENTSandSOFTWARE REQUIREMENTSspecify the respective requirements separately by trade – for example, in relation to interfaces, performance, energy consumption, or real-time behavior.
- HARDWARE TESTandSoftware Testdescribe the specific measures for testing the respective development stages. These include both automated and manual tests, e.g. functional tests, integration tests, or simulations.
All of the points mentioned are not just internal steps, but are coordinated jointly with the customer. This means: each of these terms represents a transparent, verifiable element in the project's progress.
Conclusion
At PICKPLACE, we don't believe in rigid specifications—we believe in sound engineering, good conversations, and solutions that can be developed together. That's why we focus on structure over bureaucracy, specification over speculation, and collaboration over dictation.
