If I was the Contractor, I would select the hardware, firmware and software that would meet the performance specification and cost requirements of the Contractee.
Work out a Provisional Total Costing and Time scale and submit this to the Contractee and await his response.

I’m curious which MCU or board you would go for in this case ( 8051, PIC, AVR, ARM, Arduino, ESP32, Raspberry Pi, STM32, or something else ) ? From my side, I wouldn’t really consider 8051, PIC, AVR, , Arduino, ESP32, or Raspberry Pi because I feel they might not be the best fit for the requirements. For example, 8051, PIC, and AVR are a bit dated for the level of processing and connectivity we might need. Arduino and Raspberry Pi are great for prototyping but might not offer the industrial-level reliability we need. ESP32 is good for wireless applications, but if we need higher processing power not fit.

So I’m interested to know about your approach, For example, let’s say you’re familiar with PIC. Would you try to find a PIC model that fully meets our requirements, or would you instead lean toward something like an ARM controller because it’s more commonly used in the market right now? Or maybe you’d have a completely different approach?

I’m trying to understand the thought process here. Any specific MCU suggestion you give would be really useful because my next question will depend directly on that choice?

EDIT

shouldn’t we first list what features are actually required from the MCU?
For example:

• Do we need I2C/SPI/UART (and how many instances of each)?
• How many GPIO pins are required?
• Do we need timers, ADC/DAC, PWM channels?
• What about memory, clock speed, or power consumption

 

I’m curious which MCU or board you would go for in this case ( 8051, PIC, AVR, ARM, Arduino, ESP32, Raspberry Pi, STM32, or something else ) ? From my side, I wouldn’t really consider 8051, PIC, AVR, , Arduino, ESP32, or Raspberry Pi because I feel they might not be the best fit for the requirements.

Hi Embed,
At this point in the product development, you just do not know what is 'the best'.
These details are decided by the Contactor during the preparation of his Tender documents.
Who will have chosen the materials and their costs in order that they meet the technical Specification, Cost and the Supply date set by the Contractee.

One parameter I don’t see mentioned in your listing is the possible Certification requirement for the product.

It can be a lengthy and expensive process, where a sample of the final product is submitted to a ‘Test House’ for testing to ensure that that product meets the required Statuary standards.

It is usually the responsibility of the Contractee.

E

 

I’m curious which MCU or board you would go for in this case ( 8051, PIC, AVR, ARM, Arduino, ESP32, Raspberry Pi, STM32, or something else ) ? From my side, I wouldn’t really consider 8051, PIC, AVR, , Arduino, ESP32, or Raspberry Pi because I feel they might not be the best fit for the requirements. For example, 8051, PIC, and AVR are a bit dated for the level of processing and connectivity we might need. Arduino and Raspberry Pi are great for prototyping but might not offer the industrial-level reliability we need. ESP32 is good for wireless applications, but if we need higher processing power not fit.

So I’m interested to know about your approach, For example, let’s say you’re familiar with PIC. Would you try to find a PIC model that fully meets our requirements, or would you instead lean toward something like an ARM controller because it’s more commonly used in the market right now? Or maybe you’d have a completely different approach?

I’m trying to understand the thought process here. Any specific MCU suggestion you give would be really useful because my next question will depend directly on that choice?

EDIT

shouldn’t we first list what features are actually required from the MCU?
For example:

• Do we need I2C/SPI/UART (and how many instances of each)?
• How many GPIO pins are required?
• Do we need timers, ADC/DAC, PWM channels?
• What about memory, clock speed, or power consumption

So you now have the designers hat on .

Totally different to the requirement or specification stage .
At previous stages , unless it's a requirement, small things like which MCU to use are un import.
Think if you purchasing a car .
I guess you care is it ev , ice , hybrid or you could have as your requirement that it needs to do x miles after a refill .
But you would unlikely to put on your requirements that's it's a Honda xxx engine or even it must have 6 cylinders.

When it comes to designing , the first thing a company does is say what do we have already that can do this , or can be adapted to do the job.

So in your example , if we made a commercial board that had say an AMD processor , we would look first if that did the job .

Your talking into the trap of jumping procedures .
To be honest , it's a perfect example of what happens in the majority of contracts, the requirements are normally written with an idea of what's available / possible , and how we expect it .

It's only in management classes that we see the perfect system of each stage being independent of the previous and post

This process is also a reason big projects, government / military so wrong .

The classic example they teach in good management schools is Apollo space craft.

Take 13, with the two different co2 filters. Now that could be argued it was a requirement fail, in that there should have been a requirement to make them the same , but the two ships were designed by two different companies , to two different contracts , to two different time scales, with each filter optimised to its usage/ space / weight
Would if the two companies should tell the other what filter to use ?
Out of interest , I understand though can't find reference , both filters were out sourced to the same 3rd party company !

Your original question was on lines of how is this done in industry , I think your finding the problems with this business school model when it hits reality , and the problems of trying to compartmentalise each bit

 

Your original question was on lines of how is this done in industry

I’m a bit unsure how to continue my learning, because some parts of the process are simply out of my hands like interacting with accounts or finance teams, calculating costs, sourcing materials, or dealing with actual end users. These are things that, in real projects, involve multiple departments.

My focus right now is more on understanding the methodology and flow from start to end and seeing how decisions are usually made at each stage, even if I can’t perform all the real-world tasks myself.

 

These details are decided by the Contactor during the preparation of his Tender documents.

I understand that in a real project, detailed component selection, cost evaluation, timelines, and any certification requirements would be the responsibility of the Contractor. My exercise here is more about learning the methodology and what typically happens at each stage

I’m thinking of slightly reframing my question: let’s assume my PRD is now complete, but you’ve pointed out some gaps, which I fully agree with. Could you guide me on what I should do next to really learn each step? I want to try going through the process myself. We can skip things like costing and certification for now. My main focus is on the specification and design stages, which I really want to understand thoroughly through this project.

That’s why I previously listed several MCU and board options and explained my reasoning for why I wouldn’t select them. I also provided a case to understand what you, as the Contractor, might do in such a situation.

 

I’m a bit unsure how to continue my learning, because some parts of the process are simply out of my hands like interacting with accounts or finance teams, calculating costs, sourcing materials, or dealing with actual end users. These are things that, in real projects, involve multiple departments.

My focus right now is more on understanding the methodology and flow from start to end and seeing how decisions are usually made at each stage, even if I can’t perform all the real-world tasks myself.

can I ask then, if your wanting to only understand methodology and flow, why your going down to details ?
all you have to do is describe what the expected input and output of each stage is.

I.e. requirement: capture in broad terms the needs, what must happen and what mustn't happen .

 

can I ask then, if your wanting to only understand methodology and flow, why your going down to details ?
all you have to do is describe what the expected input and output of each stage is.

I wanted to understand all these things through a real example, which is why I wrote the requirements. My idea was then to convert those requirements into specifications and design. I feel that in the specification stage, decisions are taken based on the requirements we basically create the SRD, which is a technical document. For example, it should outline what controller we need, what sensors, cameras, or RFID modules are required, and how the access system sends data to the server—TCP/IP, HTTP, MQTT, and so many etc.

Then in the design stage, we focus on things like selecting the MCU based on the specification, choosing the RFID model for the space, and other basic design decisions. That’s why I was thinking about creating the SRD first, and then moving to the design stage.

This is basically the flow I had in mind

 

I wanted to understand all these things through a real example, which is why I wrote the requirements. My idea was then to convert those requirements into specifications and design. I feel that in the specification stage, decisions are taken based on the requirements we basically create the SRD, which is a technical document. For example, it should outline what controller we need, what sensors, cameras, or RFID modules are required, and how the access system sends data to the server—TCP/IP, HTTP, MQTT, and so many etc.

Then in the design stage, we focus on things like selecting the MCU based on the specification, choosing the RFID model for the space, and other basic design decisions. That’s why I was thinking about creating the SRD first, and then moving to the design stage.

This is basically the flow I had in mind

my thought is, you imply on the one hand you don't want to / are unable to go into some bits, but want to go into otheres on depth .

im confused as to what you want then,
a suggestion,

for the process you want to follow, can you give a one paragraph description of the aim, input and output of each process?
I put it to you, that unless you have a clear requirment of what you want , without going into how your going to implimemt that , you are failing your own process !

 

can you give a one paragraph description of the aim, input and output of each process?

So here’s how I’m thinking about the whole process from my learning perspective:

1) Requirement Stage (PRD)
The Product Requirement Document (PRD) defines what the system must do and must not do. It doesn’t say how to do anything, just what must happen and what mustn’t happen. The input is stakeholder problems, expectations, and constraints, and the output is a draft PRD.

This is where we figure out what the system actually needs to do. We gather all the problems, constraints, and expectations from the “stakeholders” (even if, in my case, I’m playing that role myself). The PRD captures the system’s goals, limitations, and desired behaviour without specifying implementation details. It’s essentially the blueprint of what the system must achieve.

2) Specification / SRD Stage
Once the PRD is ready, the System Requirement Document (SRD) translates those requirements into technical specifications. Inputs are the PRD. The output is the SRD, which details expected system behaviour, interfaces, performance targets, communication protocols, and data flows but it does not prescribe exact hardware components yet.

I see this stage as defining how the system should behave technically. It sets the technical expectations without locking in component choices.

3) Design Stage
This is where the “how” is actually planned. The inputs are the SRD, available hardware/software options, and prototyping results. The output is a design document specifying the chosen components, system architecture, and detailed system layouts like MCU selection, sensor models, RFID readers, cameras, and network modules.

In other words, the design stage maps the technical specifications from the SRD to real hardware and software. Decisions such as which MCU or board to use, which sensors, and how the system modules interact are made here, ensuring the system meets the requirements defined in the SRD.

4) Development stage
Here, the design plans are turned into actual working systems. Inputs are the finalized design documents, development tools, and software libraries. Outputs are prototypes or production-ready hardware/software that implement the design.

It’s the stage where the system is built according to the specifications, tested in prototype form, and refined to produce a fully functional product ready for deployment.

5) Deployment Stage
The aim of this stage is to roll out the system and verify its performance in the real environment. Inputs include the fully developed system and deployment plans, while outputs are an operational system monitored for performance and feedback.

This stage ensures the system works as expected and provides feedback that can be looped back into a new discovery phase. Any lessons learned or issues identified feed into the next development cycle, making the process iterative and continuously improving.

 

So here’s how I’m thinking about the whole process from my learning perspective:

1) Requirement Stage (PRD)
The Product Requirement Document (PRD) defines what the system must do and must not do. It doesn’t say how to do anything, just what must happen and what mustn’t happen. The input is stakeholder problems, expectations, and constraints, and the output is a draft PRD.

This is where we figure out what the system actually needs to do. We gather all the problems, constraints, and expectations from the “stakeholders” (even if, in my case, I’m playing that role myself). The PRD captures the system’s goals, limitations, and desired behaviour without specifying implementation details. It’s essentially the blueprint of what the system must achieve.

2) Specification / SRD Stage
Once the PRD is ready, the System Requirement Document (SRD) translates those requirements into technical specifications. Inputs are the PRD. The output is the SRD, which details expected system behaviour, interfaces, performance targets, communication protocols, and data flows but it does not prescribe exact hardware components yet.

I see this stage as defining how the system should behave technically. It sets the technical expectations without locking in component choices.

3) Design Stage
This is where the “how” is actually planned. The inputs are the SRD, available hardware/software options, and prototyping results. The output is a design document specifying the chosen components, system architecture, and detailed system layouts like MCU selection, sensor models, RFID readers, cameras, and network modules.

In other words, the design stage maps the technical specifications from the SRD to real hardware and software. Decisions such as which MCU or board to use, which sensors, and how the system modules interact are made here, ensuring the system meets the requirements defined in the SRD.

4) Development stage
Here, the design plans are turned into actual working systems. Inputs are the finalized design documents, development tools, and software libraries. Outputs are prototypes or production-ready hardware/software that implement the design.

It’s the stage where the system is built according to the specifications, tested in prototype form, and refined to produce a fully functional product ready for deployment.

5) Deployment Stage
The aim of this stage is to roll out the system and verify its performance in the real environment. Inputs include the fully developed system and deployment plans, while outputs are an operational system monitored for performance and feedback.

This stage ensures the system works as expected and provides feedback that can be looped back into a new discovery phase. Any lessons learned or issues identified feed into the next development cycle, making the process iterative and continuously improving.

quick read, thats impressive, but feels a bit AI generated , but still impressive

https://www.productplan.com/glossary/product-requirements-document/

what your describing is in managment speak the waterfall process,
your asking about real industry ,
yes this used to be taught in managment training,
now its counter argumented with the agile process, which is basically the opposite of the waterfall process.

the only general comment on your process would be its normal to produce as the conclusion of each stage a document, dated, approved and tracable released document, your process only has draft docs.

 

the only general comment on your process would be its normal to produce as the conclusion of each stage a document, dated, approved and tracable released document, your process only has draft docs.

At this point, I feel I have a partially completed PRD that captures the requirements at a broad level. Now, I’m mainly struggling with the second stage (SRD), because my next step is to learn how to translate that PRD into a proper System Requirement Document.

From my perspective, this is the critical part where the requirements start becoming technical defining system behaviour, interfaces, performance criteria, and communication flows, but without locking into exact hardware or software yet. I understand that in real industry practice, each stage would typically end with a formally reviewed, approved, and traceable document. In my case, since this is more of a learning exercise, I’m treating my PRD as a draft version and now want to focus on producing an SRD that feels as close as possible to what’s actually expected in industry.

So, to put it simply: my PRD is ready enough, and my challenge now is how to correctly bridge it into the SRD stage capturing the technical requirements in a structured way.

 

At this point, I feel I have a partially completed PRD that captures the requirements at a broad level. Now, I’m mainly struggling with the second stage (SRD), because my next step is to learn how to translate that PRD into a proper System Requirement Document.

From my perspective, this is the critical part where the requirements start becoming technical—defining system behaviour, interfaces, performance criteria, and communication flows, but without locking into exact hardware or software yet. I understand that in real industry practice, each stage would typically end with a formally reviewed, approved, and traceable document. In my case, since this is more of a learning exercise, I’m treating my PRD as a draft version and now want to focus on producing an SRD that feels as close as possible to what’s actually expected in industry.


So, to put it simply: my PRD is “ready enough,” and my challenge now is how to correctly bridge it into the SRD stage capturing the technical requirements in a structured way. That’s the step I’m most keen on learning right now.

do you want to write a srd or learn / describe the process ?

the difference is to write the srd, you need to be able to know how to design what is specified in the prd .
which I think you said you don't know how to do , and im not certain the forum has the bandwidth to design what you describe in thd prd.

if you want to know and describe the process I think you have covered that.

 

the difference is to write the srd, you need to be able to know how to design what is specified in the prd .
which I think you said you don't know how to do , and im not certain the forum has the bandwidth to design what you describe in thd prd.

Yes, I get what you mean I know actually writing a full SRD requires proper design knowledge, which I don’t fully have yet. But my plan is to attempt creating an SRD for my PRD as a learning exercise. Even though I’m not an expert, with guidance and feedback from experienced people like you, I can definitely try to describe it in detail

MCU - RFID Reader.
MCU - Biometric Reader
MCU - Ethernet Module
MCU - EM Lock: Relay driver circuit
MCU - RTC
MCU - EEPROM
MCU - LCD
MCU - Camera
MCU- GSM


I have drafted an initial version of the SRD. It is not yet complete, but my understanding is that at this stage we decide what modules and components are required in order to fulfill the PRD, and why each of them is needed

I am just putting my thoughts here.

SRD 1. The MCU is needed to coordinate all subsystems. it collects data from (RFID, biometric, camera), makes access decisions, drives the EM lock, updates the LCD, and manages communication with the server.

SRD2. Authentication Module
The system shall include an RFID reader to identify users via contactless cards.
The system shall include a biometric module.
The system shall integrate a camera for capturing images during access attempts.

SRD3. The system shall drive an electromagnetic lock to physically secure doors.

SRD4 The system shall include local Storage ( EEPROM ) to maintain user credentials and logs.

SRD5. The system shall include an RTC for accurate timekeeping.

SRD 6. The system shall use an LCD display to show messages and system status.

SRD 7. The system shall provide audio-visual indicators. Buzzer/LED Indicators

SRD 8 Wi-Fi / GSM Module (optional) in case Ethernet is not always available

SRD 9. DC supply with backup (SMPS + battery).

SRD 10 Tamper Switch to detect enclosure opening.

 

Now I know what hardware components are needed to make access control system. Let’s take the case of the RFID reader. There are so many options available in the market. RFID Readers So my question is, which RFID reader would you recommend? Or, if you were in my place, which one would you select? Because if I just pick one randomly, and later its performance turns out not to be good enough, then I’ll have to replace it with another one. Wouldn’t that approach waste a lot of time?

How would you decide and select specific one based on the requirement ?