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,

That's not what "best effort" requires. While the expectations are, indeed, pretty onerous, they do not require that you bankrupt yourself. The other party's economic needs have to be predominant, but you do not have to ignore your own.

Best Efforts, Commercially Reasonable Efforts, and Reasonable Efforts Provisions in Commercial Contracts

Interpreting "best efforts" vs "reasonable efforts" in contracts | BD&P

 

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.

Thanks for pointing this out. The way I look at it, this process really has two steps. First, the customer writes down the requirement document in the way they think the system should work. Then the contract engineer/vendor reviews it and comments back on what’s technically possible, what isn’t, and what needs adjusting. So my version is more like the “customer side draft.” After review, unrealistic parts would get refined into something more practical.

 

That's not what "best effort" requires. While the expectations are, indeed, pretty onerous, they do not require that you bankrupt yourself. The other party's economic needs have to be predominant, but you do not have to ignore your own.

Best Efforts, Commercially Reasonable Efforts, and Reasonable Efforts Provisions in Commercial Contracts

Interpreting "best efforts" vs "reasonable efforts" in contracts | BD&P

MY apologies for trying to get the point over that english can be dangerous and not mean what you might think and in so doing missing the nuances of what my example means

@Embededd Please, although my example is valid, for the sake of redability and brevity, I did simplify. If you come to a legal definition, refer to @WBahn

 

PR1 : Unauthorized person may follows an authorized user through a door without presenting their own credentials. This is a big risk because important places like server rooms, labs, and storage areas can be exposed if there is no strong authentication

Solution: The system shall address tailgating through a combination of physical and electronic controls. The system shall authenticate and allow only authorized personnel through RFID smart cards, biometrics, or facial recognition. To enforce one-at-a-time entry, the access points shall be equipped with mechanisms such as mantraps (a two-door vestibule where only one person is allowed at a time) or turnstile-style speed gates that open only for a single authenticated person. Where physical infrastructure does not allow for mantraps or gates, the system shall rely on video analytics integrated with cameras to detect if more than one individual enters on a single authentication. Whenever a suspected tailgating event is detected, the system shall generate an alert within thirty seconds and shall be sent to security staff

PR3: Exit doors must unlock automatically during emergencies such as fire or gas leaks to ensure life safety. However, this creates a loophole: if someone deliberately triggers a false alarm, doors may unlock and allow unauthorized entry.

Solution: the system shall unlock doors in a controlled, directional way. Exit paths will always unlock from the inside to let people evacuate, but will remain locked from the outside. External entry points shall only unlock if both the fire alarm and in-building detectors confirm a real emergency. For critical zones, an authorized officer’s override may be required to open main entries, while all exit routes remain fail-safe. Every emergency unlock event shall be logged with timestamp, door ID, and trigger source. Administrators will receive immediate alerts, and any event later identified as a false alarm shall be flagged for review.

PR4: During power cuts or network outages, access systems may stop working, leaving doors either locked (blocking staff) or unlocked (risking intrusion).

Solution: The system shall automatically switch to backup battery power the moment the main power supply fails, ensuring uninterrupted operation. It shall continue on battery for at least 8 hours, during which all authorized users can access doors while unauthorized attempts remain blocked. When the battery capacity falls to about 30 minutes, the system shall issue a low-battery alert to administrators. If the battery becomes fully depleted, all doors shall automatically revert to a secure locked state, and administrators shall be notified within 15 minutes. Once main power is restored, the system shall return to it without manual intervention.

In case of network failure, the system shall enter an offline mode where user credentials are validated against a locally cached database. All access attempts, whether successful or failed, shall be logged with user ID, timestamp, door ID, and authentication method. These logs shall automatically sync with the central server once connectivity is restored. While in offline mode, temporary visitors or new users not present in the local cache shall be denied access. The system shall support offline operations for at least 72 hours, and administrators shall receive alerts within 5 minutes of both network failure and restoration.

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.

Solution: The system shall record every access attempt, whether successful or failed, in a secure and tamper-resistant log. Each entry shall include the timestamp, user ID, door ID, and the method of authentication used. Logs shall be stored locally and synchronized with the central server to ensure availability even if the system operates in offline mode. To support investigations of security incidents, all logs shall be retained for a minimum of 90 days by default, with the option to configure retention up to 180 days based on organizational policy. Logs shall be protected against unauthorized modification or deletion, and administrators shall be able to retrieve them quickly through the dashboard for audit or compliance reviews.

 

Updating

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.

Solution: The system shall automatically synchronize user access rights with the organization’s HR and IT systems to eliminate errors and delays caused by manual management. Whenever an employee joins, changes role, or leaves the organization, their access permissions shall be updated in real time, ensuring that only active and authorized personnel retain entry rights. This synchronization shall include role-based access control, so that employees only gain access to the doors, zones, or buildings relevant to their position. In the event of employee termination or resignation, all access rights shall be revoked immediately upon update in the HR/IT system, reducing the risk of unauthorized access from outdated credentials.

The integration shall support both scheduled synchronization and real-time event-driven updates. The system shall maintain a secure local cache of user data so that access control continues to function even during temporary HR or network outages, with all changes reconciled automatically once connectivity is restored. All user management actions, including creation, modification, and revocation, shall be logged for audit purposes

PR7: Administrators don’t have one central place to monitor and manage the whole system, making it harder to respond quickly.

Solution: The system shall provide a centralized dashboard that gives administrators a real-time overview of all access control activities across the organization. From this interface, authorized administrators shall be able to monitor door status (locked, unlocked, forced open, or held open), view live and historical access logs, and track authentication attempts in real time. The dashboard shall also display system health indicators, such as battery status, network connectivity, and device availability, allowing quick detection of failures or anomalies.

The dashboard shall support configurable alerting, ensuring that critical events such as repeated failed access attempts, forced door openings, power failures, or network disruptions trigger immediate notifications to administrators via SMS, email, or on-screen alerts. These alerts shall include contextual information such as the location of the door, user ID (if available), and timestamp, enabling administrators to respond quickly and effectively.

The dashboard shall allow filtering and search functions across logs by user ID, door ID, time range, or authentication method. Historical reports shall be exportable in multiple formats (e.g., CSV, PDF) for compliance and audit purposes. The system shall also support role-based administrative access, ensuring that sensitive functions (such as revoking credentials or changing door access rules) can only be performed by users with the appropriate authorization level.

PR8: If the access control system is not designed to handle growth, future expansions such as adding new doors, users, or sites can overwhelm the system, causing degraded performance, data inconsistencies, or outright failures. For example, a system designed for a single building may not cope well if the organization later decides to secure multiple branch offices. Similarly, as the number of users increases into the thousands, the system may become slow in verifying credentials, resulting in access delays, frustrated users, and potential security gaps if the system times out or fails under load. Without scalability, the system becomes a bottleneck and eventually unusable, forcing costly replacements or migrations.

Solution: the system shall be architected for horizontal and vertical scalability from the beginning. It shall be capable of supporting at least 10,000 active users, 500 secure doors, and multiple sites connected over a network, without performance degradation. Authentication response time shall not exceed 2 seconds under full system load. The system shall employ a modular architecture, allowing new controllers, readers, or servers to be added without requiring a full redesign. All configurations, user databases, and logs shall be centrally managed, with replication across sites to ensure consistency.

As growth occurs, administrators shall be able to add new users, roles, or access policies dynamically, without downtime. For multi-site organizations, the system shall support distributed deployments with local autonomy (so each site can continue operating independently if disconnected from the central server) while still synchronizing data once connectivity resumes. Performance benchmarks shall be defined and tested to verify that the system maintains stability and responsiveness under expected peak load conditions.

PR9: In modern security environments, access control systems rarely operate in isolation. If the system cannot integrate with third-party services such as video surveillance, fire alarms, or HR databases, organizations will face fragmented security operations. For example, if a person badges into a secure room but the CCTV feed is not linked to that event, administrators lose valuable forensic evidence. Similarly, if employee data in the HR system is not synchronized with access control, a former employee could retain access longer than intended, creating a security risk. Lack of integration leads to duplicate data entry, higher administrative overhead, and delayed responses during emergencies.

Solution: The system shall expose secure APIs and standard integration protocols (such as REST or MQTT) for seamless connectivity with third-party platforms. The design shall allow integration with video surveillance systems so that door access events can be paired with corresponding camera footage. It shall also support automatic synchronization with HR databases, ensuring that when an employee is onboarded, promoted, or offboarded, their access rights update instantly across the system. Integration with fire alarm and building safety systems shall be supported, enabling automatic door unlocks or escalations during emergencies while preserving security controls.

 

This is the requirement document I have created based on my best knowledge. It may still need improvements, but my current focus is on the original question and moving to the second stage: the System Specification (SRD).

At this stage, I am interested in understanding what should happen in the specification stage. For example, is this where we select components like MCU, sensors and protocols?

 

This is the requirement document I have created based on my best knowledge. It may still need improvements, but my current focus is on the original question and moving to the second stage: the System Specification (SRD).

At this stage, I am interested in understanding what should happen in the specification stage. For example, is this where we select components like MCU, sensors and protocols?

One of the biggest problem with the theoretical process your following , is you have feedforward , but no feedback..
You seemed to be putting into the requirement what should have been on the specification and vice versa

 

One of the biggest problem with the theoretical process your following , is you have feedforward , but no feedback..
You seemed to be putting into the requirement what should have been on the specification and vice versa

To understand the overall process, I am playing both roles from the customer side, where problems and expected solutions are defined, and from the technical side, where those requirements need to be implemented. Initially, I thought the customer’s role is to share the problems and what kind of solution they expect, and the technical person’s role is to implement those requirements.

That’s why I feel the customer’s draft (PRD) is already ready, and now the technical person should write the next draft, which will be the System Requirement Specification (SRD). I am not fully sure what exactly should be included in the SRD, and that is what I want to understand better

 

To understand the overall process, I am playing both roles from the customer side, where problems and expected solutions are defined, and from the technical side, where those requirements need to be implemented. Initially, I thought the customer’s role is to share the problems and what kind of solution they expect, and the technical person’s role is to implement those requirements.

That’s why I feel the customer’s draft (PRD) is already ready, and now the technical person should write the next draft, which will be the System Requirement Specification (SRD). I am not fully sure what exactly should be included in the SRD, and that is what I want to understand better

did you include a review in the prd process of the doc ?

 

did you include a review in the prd process of the doc ?

The first PRD I created was in post #12, and my intention was to have it reviewed. @WBahn already reviewed it and gave feedback, and based on that I updated the requirements and posted them again. #24, #25

my main intention is more about learning how to move from requirements to the specification stage – like what exactly should be included there, for example choosing whether to use 8051, PIC, AVR, Arduino, ESP32, Raspberry Pi, STM32 or any other and why specific one and selecting hardware or protocols based on the requirements.

 

I don’t know if asking this kind of question in a forum thread is right or wrong, but it’s out of curiosity, so I want to put in my best effort. I also understand that what I’m asking is not simple. it’s the kind of thing only experienced engineers can really explain. I’m glad that I’m getting such valuable help here.

 

The first PRD I created was in post #12, and my intention was to have it reviewed. @WBahn already reviewed it and gave feedback, and based on that I updated the requirements and posted them again. #24, #25

if your happy with that then great,
you said
"
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).
"

and I think your getting a good idea of the process, and the nuances / problems with a rugged process.

what im getting at, is in industry , each part of the process would be reviewed , then when ready signed off and published as required, including such things as time / date , written by, approved by as part of the process,

we have not seen that document. unfortunatly , in industry documentation is the main product , and the basis of a lot, and younsay young ant to learn whats happens in industry , so im highlighting this.

you do highlight the problem of this sort of game, being both side s. like p,saying yourself at chess, its always going to be a draw, and you are unlikely to learn new chess moves.

best wishe

 

I don’t know if asking this kind of question in a forum thread is right or wrong, but it’s out of curiosity, so I want to put in my best effort. I also understand that what I’m asking is not simple. it’s the kind of thing only experienced engineers can really explain. I’m glad that I’m getting such valuable help here.

the problem is probably not lack of experienced engineers here, its more that this is a managment process, developed in managment schools ..
real engineering process is much more of a "mess".

in reality , each and every company has their own variation on the process , ranging from the class "back of fag packet" through to "government / space" processes.

I bet Boeing space has a very different process to that of space X .

 

what im getting at, is in industry , each part of the process would be reviewed , then when ready signed off and published as required, including such things as time / date , written by, approved by as part of the process,

I understand your point. I don’t know how others handle it, but my idea was that I should first create a single document and then get it reviewed at every stage before passing it on to the technical side. That’s why I prepared the Excel sheet with fields like date and author and I can also add extra columns for review comments and approvals. I had uploaded this sheet earlier in post #12 for the same reason

But I noticed that only 3 members actually looked at the Excel sheet, so I thought it might be better to post the requirements directly in the thread, so experts can easily see and review them.

 

hi Embed'
The Contractee is the originator and provider of the Specification document created by an 'in-house' project team, which is then submitted to the external Contractors, initially inviting them to submit tenders.

E

 

hi Embed'
The Contractee is the originator and provider of the Specification document created by an 'in-house' project team, which is then submitted to the external Contractors, initially inviting them to submit tenders.

Thanks, The document I created how would you classify or name it in industry terms? Would it be considered a Product Requirement Document, Product Specification Document, or something else?

I think it would be considered a Product Requirement Document (PRD)

I understand your point about the tendering process, but in my case, we can assume the contract is already awarded, so I don’t need to go through that step.

My main focus right now is learning how to move from a PRD to an SRD, and understanding what exactly should go into the specification stage. For now, I am treating my PRD as complete because I don’t have any other to review it.

 

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

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

Based on your 4D process, I understand how the PRD fits into the Discover phases. Where, in your experience, does the Specification stage (SRD) fit into this cycle? What exactly should be captured at that stage. Is it mainly component selection like MCU, sensors, protocols, and software requirement, or more about detailing system behaviour?

@Ya’akov

 

I think it would be considered a Product Requirement Document (PRD)

Hi Embed,
I would classify it as a 'Draft In-House Product Requirement Document' which is created by an 'in-house' project team, which includes members of the Marketing, Sales, Finance and Engineering Departments.

E

 

I would classify it as a 'Draft In-House Product Requirement Document' which is created by an 'in-house' project team, which includes members of the Marketing, Sales, Finance and Engineering Departments.

Agree, that makes sense. I consider my document a draft PRD based on what I know so far. It might still need improvements, but since this is a learning exercise and not an actual project, I’m treating it as sufficiently complete for practice purposes. My next step is to move on to the SRD stage, focusing on translating these requirements into specifications. I’m curious what exactly happens at that stage? Is it mainly about selecting components like MCU, sensors, protocols, and software requirement, or is it more about detailing the system’s behaviour?

 

Is it mainly about selecting components like MCU, sensors, protocols, and software requirement

Hi Embed,
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.

E