Greetings -

I’m trying to get a better picture of how the full product development cycle actually works in real industry (This is not homework or anything, just for my own learning).

Say a company sets up a new plant and instead of keeping an in-house team, they outsource me as a contract engineer to deliver an access control system (for gates/doors).

To make it easier I am dividing the process into stages

• Requirement
• Technical specification
• Design
• Development
• Testing
• Installation

Each step can turn into a whole topic by itself, so I don’t want to mix everything together. I’m planning to go step by step (later I’ll get into things like specification, design, development, testing, etc.). For now, I just want to stick with the requirement stage.

What does a proper requirement doc from the company side usually look like? What kind of details do experienced engineers expect the client to provide before even starting design?

 

From my experience as a contractor, it is not as clean and tidy as one would imagine.

Starting with the requirement and specification, the client has a good idea of the requirement but is unable to state the specifications in engineering terms.

The contractor has to sit down with the client and layout the specification. More often than not, the requirements will change as the client and end user get a better feel of how the instrument functions and operates.

Hence, one can expect a number of iteration cycles before the project is completed.

 

Starting with the requirement and specification, the client has a good idea of the requirement but is unable to state the specifications in engineering terms. The contractor has to sit down with the client and layout the specification.

Thanks for sharing your experience, that really helps me understand the practical side.

Would you be open if I prepare a sample requirement document from the client’s perspective, and you review it as if you’re the contractor? I think that kind of discussion would give me a clearer idea of what’s usually missing or needs to be improved in requirement docs.

 

hi Embed,
I do not see any mention of Development, Prototype, final Product costing in your listing.
In which stage of your listing do you think it should appear.?
E

 

Let me try to give you a hypothetical example.

Client wants a device to display dewpoint. It should have a power ON switch, a display that shows dewpoint, and a temperature unit scale to select °C or °F.

As a contractor, you have to squeeze out details such as, AC or battery powered, size, style, weight and material of the box, type of display, LED or LCD, back lighting, number of digits and decimal place, resolution and accuracy, limits and alarms, external readout, calibration procedures, etc.

 

I do not see any mention of Development, Prototype, final Product costing in your listing.

I did mention development in my first post, for me that stage includes things like prototyping and later moving towards the PCB board.
You’re right, though, I completely missed out on costing. Honestly, I don’t have much idea about how/where exactly costing comes into the flow, so I’d like to hear your thoughts on which stage it usually fits best.

 

In my last position which was technical management at a university in IT, telecommunications, and research instrumentation, I worked with the other director to blend and codify our methods that came from industry and on his side, the military as well.

The high level version is a cyclic, iterative process we called 4D after the phases:

1. Discover
2. Design
3. Develop
4. Deploy

We chose verbs rather than nouns to emphasize the active nature.

The process starts with discovery, which uses a lightweight version of use case methodology. The product of this phase is fed into the next one: design.

We were careful not to allow any design activity prior to the Discovery phase to avoid creating damaging constraints through ignorant choices. However, once the Design phase begins, knowledge developed in the process is often used to specify additional Discover activities (feedback), which then is fed forward into the Design phase.

In fact, it is expected that any phase might feed back into the preceding one as part of the refinement of the work product.

The Design phase product is fed into the Develop phase where two activities occur: prototype(s) and production version creation, Prototyping is a critical activity, it accelerates development and eliminates errors earlier in the process than the production version.

The Deploy phase is also bipartite, comprising planning and rollout. Once the rollout is done, the cycle continues with a new Discover phase, targeting information gathering about the success of the deployment... and the process continues for the life of the product or system involved.

 

Say a company sets up a new plant and instead of keeping an in-house team, they outsource me as a contract engineer to deliver an access control system (for gates/doors).

Is this a real project? Because it seems to me it would be silly to contract for development of such a thing when there are likely many existing commercially available options. I have never worked at a company that developed their own access control system.

When I Google "Industrial Access Control Systems" I get 4 sponsored links and countless others.

 

Hi Emb,
You will find that most clients have a cost selling target for their product and also a profit margin for their company.

This usually sets the cost they are expecting to pay you for producing the product in agreed quantities and delivery dates.

You calculate the cost of the Design and Development and production of say 6 prototypes, based on the agreed product specification and the customers required delivery date of the product prototypes.

It is very important that you both agree the product's final specification, and it is confirmed in writing.

Submit your costing/delivery proposal to the customer and discuss and both agree to the proposal, if any changes from either side are required, re-submit the revised proposal.

State clearly to the customer that the specification is your intellectual property, and you expect them to place an order with your company to produce the product, and not invite other manufacturers to tender based on your design specification.

Get the customers Order to produce the prototypes, build, supply and invoice the customer for this work and the design rights.

E.

 

What does a proper requirement doc from the company side usually look like? What kind of details do experienced engineers expect the client to provide before even starting design?

My experience is that this ends up being all over the map. Some customers have a very firm idea not only of what they want, but how they want it achieved. Others have, at best, a vague notion of what they are trying to do and no idea at all about how to achieve it. Then you have every possible point in between those extremes. You also have the situation in which the customer believes they know exactly what they want, but in reality they don't really understand the problem that they are actually trying to solve. Complicating things are customers that are paranoid about you stealing their ideas, and so they insist on only telling you what they believe you need to know, despite that often resulting in you not having critical information needed to do the job properly.

Thus, establishing the requirements is often a messy and iterative process in which you and the customer need to have real conversations in which both sides actually listen to the other and strive to educate the other side about the concerns and realities from their perspective. I've generally found that playing devil's advocate and doing a lot of "what if" gaming can really help both sides hone in on what the true problem is that is being addressed by the project, what is really important and not important, and what actually constitutes success at the end of the day. It's also been my experience that what both sides agree to at the beginning seldom survives intact through to the end. Things that weren't foreseen come up for a variety of reasons that force prior decisions to be revisited and revised, so avoid making firm, fixed-price promises if at all possible. If you must make a fixed-price bid, be sure that it is sufficiently padded to allow for the inevitable creep.

Now, I should point out that the work I did was probably more susceptible to a messy process than most because we specialized in one-of-a-kind, lunatic-fringe type projects and were often a design house of last resort after everyone else told the customer that what they wanted to do couldn't be done. We were usually able to find a way to do it.

Our nightmare customers were the ones that had prototyped a discrete-electronics solution that worked (more or less) and thought that they were just paying us to take their design and implement it on a chip. It often took serious effort to get them to realize that we needed to start over from scratch to design the chip because the games and techniques that apply to discrete analog design are fundamentally different, and often at odds, with the games and techniques used in integrated designs. Very different strengths and weaknesses and different things that you do and don't have control over.

 

Very true. It comes back to the XY problem.

https://en.wikipedia.org/wiki/XY_problem

 

I'm sharing the requirement document that I've created. This document has been written customer's point of view. In the document, each requirement is structured into two parts Problem, which define actual issue and solution, which outline proposed approach to resolve that problem.

ID	Problem	Solution	Date	Author
PR1	Person who are not allowed may enter secure areas. This is a big risk because important places like server rooms, labs, and storage areas can be exposed if there is no strong authentication	The system shall authenticate and allow only authorized personnel using secure methods such as RFID smart cards, biometric fingerprint scanning, or facial recognition.	2025-08-21
PR2	Fake or copied credentials (like cloned RFID cards) may compromise security and allow unauthorized access.	The system shall use protections like encryption and unique IDs to stop fake or copied credentials. If someone tries to use a cloned card, the system will detect and block it.	2025-08-21
PR3	In emergencies like fire, if exits remain locked, person may get trapped inside, creating a life-threatening situation.	The system shall connect with the fire alarm so all exit doors open automatically in an emergency. This shall happen instantly without delay	2025-08-21
PR4	Power cuts or network failures can stop the access system from working, making doors either unusable or unsecured	The system shall keep working during power cuts using backup batteries. If the network fails, doors shall still work in a safe mode.	2025-08-21
PR5	If access attempts are not recorded, it becomes hard to check what happened during a security incident. Without logs, it is impossible to find who entered and when.	The system shall log every access attempt, whether successful or failed. Each log entry shall include timestamp, user ID, door ID, and method of authentication, stored securely for a minimum of 90 days.	2025-08-21
PR6	Manual user management is error-prone, inefficient, and time-consuming. HR staff or administrators may forget to revoke access for employees who resign, increasing the risk of unauthorized access.	The system shall connect with HR and IT systems to automatically update user access. When someone joins or leaves the company, their access will be granted or removed without manual work.	2025-08-21
PR7	Administrators don’t have one central place to monitor and manage the whole system, making it harder to respond quickly.	The system will provide a single dashboard where admins can view logs, manage users, set rules, and monitor all doors in real-time.	2025-08-21
PR8	As more users or doors are added, the system becomes harder to scale and may require downtime.	The system shall be scalable to add new access points, users, or buildings with minimal configuration effort. The architecture should allow seamless expansion without disrupting ongoing operations.	2025-08-21
PR9	Without detailed reports and insights, it is difficult to notice unusual activity or detect threats early.	The system shall generate detailed access history reports, failed login attempts, and suspicious activity alerts. It shall also provide automated reports on a daily, weekly, or monthly basis for security audits.	2025-08-21
PR10	Visitors need temporary access, but if they are given unrestricted entry, it creates risks. Access should be time-bound and limited to certain areas.	The system shall allow visitors to get temporary passes or badges that only work for certain areas and for a limited time. Once the time is over, the pass will automatically expire.	2025-08-21
PR11	If too many users try to access at the same time, the system may slow down or fail, causing delays at entry points	The system shall be designed to handle at least N concurrent users simultaneously without performance degradation. Load balancing and distributed processing should be supported for large deployments.	2025-08-21

Please have a look at attached document and let me know your feedback

 

This sure looks like some kind of school assignment.

Leaving that aside, after having just glanced at the document, lots of questions start jumping out at me.

For instance, in the solution to PR2, you say that you are going to use encryption to solve the problem of someone using a cloned RFID card. If the card is truly cloned (i.e., identical to the first), how is encryption going to address the problem? It's not enough to just throw out buzz words and phrases. It is your responsibility to make a compelling case that your proposed solution will actually solve the stated problem. It doesn't have to get too far into the weeds, just far enough to make that compelling case.

In PR4, you say that "doors shall still work in a safe mode." What, exactly, is this "safe mode". What defines "safe" and exactly how should the system behave in order to satisfy that criteria. Does "safe" mean that no one is allowed to enter? Does "safe" mean that everyone that has legitimate access will be able to still enter? It's fine to say that the system shall keep working during power cuts using backup batteries, but for how long? Ten minutes? Ten hours? Ten days? What happens after the batteries are depleted?

In PR5, where does the 90 day aspect come from? Why isn't 30 days sufficient? Why isn't 180 days needed?

In PR1, how is your system going to address tailgating?

In Pr3, how is it going to prevent an adversary from triggering an emergency and then using the now open exit doors to gain entry?

Most of your solutions are way too vague to be useful or convincing.

You should probably start by taking each problem and really going into detail about the aspects of it, including brainstorming scenarios in which security can be compromised by an adversary intent on exploiting it.

 

One thing that you must be very aware of, is feature creep.
For instance, and using the same dew-meter example from above.
Let’s say you have settled that the device will be powered by rechargeable batteries. Nowadays, this would mean an USB port to recharge the battery. So far so good.

Then someone, usually not technically savvy but with a large economic influence, looks at the prototype and its USB port and thinks: “Hey! Let’s add computer connectivity to the meter.”
And then they have a hard time understanding how come the project’s timeline will be delayed a few weeks and then you want to re-quote your NRE.

 

I’m trying to get a better picture of how the full product development cycle actually works in real industry

hi Embed,
Ref Post #12:

Who has chosen that overly complex project, as an example of explaining the process of learning and the understanding of a typical product development project cycle?

E

 

Ref Post #12:
Who has chosen that overly complex project, as an example of explaining the process of learning and the understanding of a typical product development project cycle?

I chose this example because it’s interesting and quite common in offices and factories, making it relatable and practical for explaining the process of learning and understanding a typical product development project cycle. I made my attempts at #12 to write requirements, and I’m working the advice @WBahn provided to improve further

 

Each step can turn into a whole topic by itself, so I don’t want to mix everything together. I’m planning to go step by step (later I’ll get into things like specification, design, development, testing, etc.). For now, I just want to stick with the requirement stage.

hi Embed,
The point I was making is that post #12 is an overly complex specification.

I would have suggested a much simpler specification would enable the subject of a 'Project lifecycle' would be easier to explain and discuss.

E

 

It's fine to say that the system shall keep working during power cuts using backup batteries, but for how long? Ten minutes? Ten hours? Ten days? What happens after the batteries are depleted?

In this PRD4, This is all what I think the system supposed to do during a power and network failure

1. The system shall automatically and instantly switch to backup battery power whenever the main power fails, ensuring that no access activity is lost.
2. It shall continue operating on battery power for at least 8 hours, allowing authorized users to enter doors while blocking any unauthorized attempts.
3. Once the main power supply is restored, the system shall automatically switch back to the main power without manual intervention.
4. The system shall provide a low-battery warning alert when approximately 30 minutes of capacity remains. After the batteries are fully depleted, all doors shall revert to a secure, locked state. Security personnel shall be notified via automated alerts within 15 minutes of both the low-battery warning and the full battery depletion event. so they can jump in and handle it. Once main power is restored, the system shall automatically switch back to main power.

1. The system shall automatically switch to local offline mode when it detects loss of network connectivity.
2. While in offline mode, the system shall validate user credentials against a locally cached database of users and permissions stored
3. Authorized users shall still be granted access to doors, while unauthorized attempts shall be denied.
4. All access attempts (successful and failed) shall be logged locally with timestamp, user ID, door ID, and method of authentication. These logs shall be automatically synchronized with the central server once connectivity is restored.
5. Administrators shall receive an alert notification (via SMS, email, or dashboard) within 5 minutes of a network failure event and another notification once the network is restored.
6. During offline mode, temporary visitors or newly added users (who are not present in the local cache) shall not be able to access secure areas until synchronization resumes
7. The offline mode shall be capable of sustaining continuous operation for at least 72 hours of network downtime.

 

@WBahn I’ve updated the requirement. Does it make more sense now? For now, I only changed this one requirement just to show whether I’m actually following your advice or not. From my side, I’ve tried to capture what I understood, and I’ve updated it accordingly

 

@WBahn I’ve updated the requirement. Does it make more sense now? For now, I only changed this one requirement just to show whether I’m actually following your advice or not. From my side, I’ve tried to capture what I understood, and I’ve updated it accordingly

The requirement

" Administrators shall receive an alert notification (via SMS, email, or dashboard) within 5 minutes of a network failure event and another notification once the network is restored "

Is a good example of an impossible to achieve specification
example. If the admin has their phone turned off, they can not receive a message,
if the mobile phone network is down they wont receive a message,
if your system is in local mode, how will the message get out of your system ?

All situations outside of the control of the contract signee, !

Now you could say there needs to be a "mobile phone" connection , over which the above events could be sent,
but the delivery of that information is outside the contract control.

I'm afraid you have entered the world of contract specifications, where lawyers make their fortunes.

An example of the pitfalls of that,

I in English could say " do your best effort" is good enough
My meaning would be don't worry, its ok, I trust you, just do the normal good job you do
In contract terms, "best effort" means very different,
it means you must do everything you can that's legal, upto and including costing so much you go bankrupt.

A very different thing,