As an aside, no product is developed in a vacuum. Even "new inventions" are rarely revolutionary, they are rather evolutionary.

If you are trying to solve a problem, which is what a successful product does, you will have other examples of solutions to the problem or similar problems. You will have pieces of the solution already available and useful to you, and you will have examples of failed attempts (just as important as the successes).

A product design effort is broadly about two things: creating new components and integrating existing ones. Every product is part of a system which includes the user and anything in the environment it has to interact with. This is the reason your hypotheticals fall flat: you are unable to include all the necessary information because you are not dealing with something real.

Many times, in the end, the successful product looks and acts very differently from what is first imagined. This can be mitigated to some extent by focusing properly during the process from conception to delivery on the level of abstraction required for each step.

I've mentioned elsewhere the 4D methodology a colleague and I developed for project lifecycle. The 4 D's are:

• Discover (what is the problem, what is the environment it is in, and what are the constraints?)
• Design (Given the information in the Discovery, what can we create that solves the problem?)
• Develop (Given the Design, what technological and procedural creations will solve the problem in practice?)
• Deploy (Given the developed system, how do we go about delivering it so it will actually succeed?)

So, your question starts in the middle of nowhere. The client is the expert in the problem to be solved. You are supposed to be the expert in characterizing that problem so a technological solution can be created. The list of things you started this with is like something jotted down in the Design phase in some random meeting. It is neither a requirement or a specification on its own.

STEP ONE in a successful product development is to understand what the product will do that makes it useful and valuable. "Storing a picture" or anything like that isn't that. Start with a high level description of what it will be like for the user to use the product to solve the problem. That "story" will drive everything below it. It is the best way to account for all the functional requirements. You start very high level and add details as you work out what is possible given the problem, the operating environment, and the constraints—then you start writing specifications.

For example, you might have a product that needs to communicate with the Internet. When you are describing the actual use of the product you might discover that the product needs WiFI, but also cellular connectivity based on that story of how the product will be used. You might also find, for example, the product must be able to be carried easily, and resist dropping and rain.

This is done in collaboration with the expert on the problem, that is, the customer who will buy it. Sometimes it might not be the people who contact you about it rather the people who work for them who really know how the process of their jobs work and what will make them easier or even doable.

One reason consultants have a bad reputation is because when approached about doing something like "can you make me a handheld device that can read barcodes and send them to our server" they say, "of course I can" and they do, only to have the client discover that it doesn't solve the problem which wasn't the device but what the device was supposed to do.

Suddenly, though the consultant was supposedly engaged to solve one problem (the handheld device), and did it perfectly, the client is very upset the problem they wanted solved isn't. A good consultant works with the client to discover the problem to be solved using the client proposed solution as a way into it. It could turn out the client has done excellent discovery and some design, and your job will be easy going forward. I have found that clients who have to look to the outside have not done so.

What you can expect in the real world from clients is a messy list of things from various phases and at various levels of abstraction. You will find some constraints to be entirely artificial and you have to lead the client away from these when they are incompatible with success within other constraints. You will find a lack of understanding by management of the workarounds used by the workers. You will find attempts to take a system based on manual operations and automate things that are completely unnecessary because of the automation.

In consumer products, you have to talk to the consumers. You have to look at what they can buy now, why they buy it, and how you can have a market for whatever you will make.

All of these things are needed long before a single technical requirement is. You have to understand the problem before you can hope to understand how to solve it.

You have explained very well how one should think while designing a product. Your post not only help me but will also help other people who want to know more about product design.

Many many thanks @Yaakov

 

can you tell why you chose only rs232 protocol, you may have other options like wifi?

Hi P,
I thought that RS232 would be cheaper than a Wi-Fi option, do you recommend using Wi_Fi.?

Will Wi-Fi have the 'range' if some of my customers have Green houses, say a 1000 mtrs away from their homes.?

E

 

Hi P,
I thought that RS232 would be cheaper than a Wi-Fi option, do you recommend using Wi_Fi.?

I need to do some research to answer your questions. I'll be back with some research work

 

" My idea is to design and manufacture a product that will measure the Temperature and Humidity of my Green house, which is, located, approx. 50mtrs from my home.

The Green house unit will measure these parameters every minute and transmit by a radio link, using RS232 protocols, to a receiver in my house. The receiver will display and log the parameters to a SD card.

Were I the consultant, I would focus on the idea of using wireless and not the protocol. I would look for successful products that do something similar and find out what they use.

Guessing at what might be good is a waste of time. It is a solved problem, use other people’s work.

HINT: Weather stations do these things and there are many with wireless communications.

 

Were I the consultant, I would focus on the idea of using wireless and not the protocol. I would look for successful products that do something similar and find out what they use.

Guessing at what might be good is a waste of time. It is a solved problem, use other people’s work.

HINT: Weather stations do these things and there are many with wireless communications.

You are correct, Yaakov. Clients often include unnecessary constraints in their requests for a product design. They tend to jump to solutions rather than analyze their requirements. That is why I always insisted on the creation of a functional specification before I would consider accepting a task. Quite often, customers have no idea how to write a functional spec. I would explain why it is necessary, and write it for them if required, for a price, of course. Once the spec was agreed upon by both parties (in writing), A quick feasibility study is done. I divided up the project into sections to find the cost. Those usually contained: The things that I know that I know, the things that I know that I don't know and the things that I don't know that I don't know
The first first section is relatively easy to put a cost to. With the second group I make a decision on whether it is more cost effective for me to acquire the knowledge needed or farm out that section to an expert in that field and get a quote from him. The last section includes unexpected details that the customer never mentioned and I never thought to ask about. The cost of that is taken care of by doing a risk analysis.
When presented with a cost breakdown, the customer usually tries to negotiate the price. I explain that I am flexible and can reduce the cost if they let me know which features to leave out. Once they agree to a price and delivery date, a contract is drawn up which includes the functional specification, the price breakdown, an acceptance procedure, an escape clause and the terms and conditions. Customers often think of a feature that they would like to add once the project is underway so the latter includes a clause that states that any changes to the project must be requested in writing by the customer, and that this
may change the cost and delivery agreed on. This contract is signed by both parties and becomes a legal document.

Pushcar1, I hope this gives you a better understanding of how a project is created and what the specifications are used for.

 

Post what you consider, what is the next step?

This is my recommended part list

1. DHT11 (temperature and humidity sensor)
2. ESP32 Board
3. Laptop / mobile APP

ESP32 takes sensor data and sends it to laptop kept at house via Wi-Fi. MySQL databse is running on Laptop

 

You are correct, Yaakov. Clients often include unnecessary constraints in their requests for a product design. They tend to jump to solutions rather than analyze their requirements. That is why I always insisted on the creation of a functional specification before I would consider accepting a task. Quite often, customers have no idea how to write a functional spec. I would explain why it is necessary, and write it for them if required, for a price, of course. Once the spec was agreed upon by both parties (in writing), A quick feasibility study is done. I divided up the project into sections to find the cost. Those usually contained: The things that I know that I know, the things that I know that I don't know and the things that I don't know that I don't know
The first first section is relatively easy to put a cost to. With the second group I make a decision on whether it is more cost effective for me to acquire the knowledge needed or farm out that section to an expert in that field and get a quote from him. The last section includes unexpected details that the customer never mentioned and I never thought to ask about. The cost of that is taken care of by doing a risk analysis.
When presented with a cost breakdown, the customer usually tries to negotiate the price. I explain that I am flexible and can reduce the cost if they let me know which features to leave out. Once they agree to a price and delivery date, a contract is drawn up which includes the functional specification, the price breakdown, an acceptance procedure, an escape clause and the terms and conditions. Customers often think of a feature that they would like to add once the project is underway so the latter includes a clause that states that any changes to the project must be requested in writing by the customer, and that this
may change the cost and delivery agreed on. This contract is signed by both parties and becomes a legal document.

Pushcar1, I hope this gives you a better understanding of how a project is created and what the specifications are used for.

Client constraints are often arbitrary and settled on without the process needed to decide if they will contribute to the success of the project. If the client was a manufacturer of a particular wireless module, then the constraint of using the module would be reasonable since the goal of the project would be to use it as part of the solution.

If the client could get certain wireless modules very cheaply, a constraint requiring their use might make sense if the price was better than other options, but without a design ignoring that constraint and focusing only on cost and function, you wouldn't know.

If the client confused "WiFi" with wireless connectivity and specified it, that constraint is ignorance and should be ignored in favor of actually choosing a wireless technology that works best for cost.

This is true for all constraints presented outside process. Make a note and ensure that you communicate why you don't recommend that thing, if you don't, and often, you won't.

 

This is my recommended part list
1. DHT11 (temperature and humidity sensor)
2. ESP32 Board
3. Laptop / mobile APP

Hi @Pushkar1
Looks good, how will the green house unit be housed, also my green house is what is called a Cold green house, so no heating, so no power.
What will be the cheapest way to power the unit 24/7.?

E

BTW: If the greenhouse temperature drops below +10C I have to go and light a small oil fired heater in the greenhouse, so perhaps I need some sort of warning alarm in the home unit.?

 

The approach I use to monitor temperature and humidity in my workshop and garage is to use a BME280 sensor which is read using a pic12f1840 and converted to readable text. That is then sent using a HC-12 module to another HC-12 module connected to a serial post on a computer in the house. The information is requested and displayed using a terminal emulator program. (Tera Term.) I request the information by typing a # character followed by a letter character the letter selects which remote sensor responds with information. (Some of my sensors monitor voltage and current.) When I started the project I use DHT22 sensors but found that different DHT22s gave different reading when located in the same place. I found BME289s to give more consistent results.



This is one of the sensors and screen capture of a reading.


Les,

 

Hi Les,
The intention of my post #18, was to get Pushkar1 to go through the questions' and answers process of dealing with a potential Client who was requesting a quotation based on a 'verbal' specification...

In order to show him, it could be an endless task!

I will now drop the idea.

E