[SOLVED]Problem statement for the project

Thread Starter

Pushkar1

Joined Apr 5, 2021
328
Hi
I think that before writing the code for the project, we should write the simple and well-defined problem description.

Does anyone have any suggestion or advice when you write a problem statement for a project, what kind of problem statement do you write?

If you @MrChips can explain by giving example of any one project then it will be very useful for me.
 

Thread Starter

Pushkar1

Joined Apr 5, 2021
328
How can you define problems that don't yet exist? Do you mean a risk analysis?
No, Not like that

What kind of problem statement would you write for the following:

If the switch is closed and the LED is off, turn it on. Otherwise, don't change it.
 

KeithWalker

Joined Jul 10, 2017
1,947
I would nor write a problem statement for that because no apparent problem exists. A problem statement is a concise description of an issue to be addressed or a condition to be improved upon. It identifies the gap between the current (problem) state and desired (goal) state of a process or product.
 

Papabravo

Joined Feb 24, 2006
17,030
Hi
I think that before writing the code for the project, we should write the simple and well-defined problem description.

Does anyone have any suggestion or advice when you write a problem statement for a project, what kind of problem statement do you write?

If you @MrChips can explain by giving example of any one project then it will be very useful for me.
In a career spanning more than half a century -- I've never written one.
I've written boatloads of specifications for things I was going to do and updated those specifications as I did them.
 

Thread Starter

Pushkar1

Joined Apr 5, 2021
328
In a career spanning more than half a century -- I've never written one.
I would nor write a problem statement for that because no apparent problem exists.
I read somewhere that we should have a clear and well-defined problem statement before writing a program. I have understood what the problem statement is, but I do not understand how to make it.
To understand that I need to take an example which I do not understand which would be suitable example
 

click_here

Joined Sep 22, 2020
444
It is very important with a client (especially larger clients), because they will always try and get a discount at the end, or get more things added - They will always start with "That doesn't do exactly what we wanted it to do".

State exactly what the product needs to do and then get both parties to sign off on it.

If they want something changed, that's fine, but make sure you update the paperwork.
 

Thread Starter

Pushkar1

Joined Apr 5, 2021
328
It is very important with a client (especially larger clients), because they will always try and get a discount at the end, or get more things added - They will always start with "That doesn't do exactly what we wanted it to do".

State exactly what the product needs to do and then get both parties to sign off on it.

If they want something changed, that's fine, but make sure you update the paperwork.
Good suggestions for employees. BTW I'm student
 

Papabravo

Joined Feb 24, 2006
17,030
My point was that a description of a (the) problem is a nearly useless piece of fluff.
A description (specification) of what you intend to do and how something will behave is an entirely different and eminently useful document.

A statement or description of the problem might require a sentence or two. A paragraph at most.
Some of my specifications ran to several hundred pages. There is a great deal of difference between a paragraph and several hundred pages.
 

Papabravo

Joined Feb 24, 2006
17,030
Good suggestions for employees. BTW I'm student
And because you are a student you are asking questions and we are trying to provide useful insight and advice. You can take it or ignore it -- however you may be inclined. You may be a student, but the professor is your customer. The more you treat him that way the more respect you will garner.
 

Thread Starter

Pushkar1

Joined Apr 5, 2021
328
I'm curious @Papabravo to see What kind of problem statement/discription would you write for the project " SMS based fire detection system using smoke and temperature sensor"
 

Papabravo

Joined Feb 24, 2006
17,030
I'm curious @Papabravo to see What kind of problem statement/discription would you write for the project " SMS based fire detection system using smoke and temperature sensor"
I said in #5 that I never write them. I would not have a clue.
You're probably in a better position than I am to write such a paragraph. I've never worked with smoke detection, temperature sensors, or SMS anything.
 
Last edited:

click_here

Joined Sep 22, 2020
444
I'm curious @Papabravo to see What kind of problem statement/discription would you write for the project " SMS based fire detection system using smoke and temperature sensor"
Okay, so... the client has come to you and said that they need a device that does that.

First thing is to in plain language go through the assumptions verbally, taking notes. I would start with, "You want an SMS when there is a fire detected, right?"

You need to do a bit of research and work out what temperature and smoke detectors are usually spec'd at.

You then need to have a look into what phone networks and what providers are available where the client wishes to use the product. What carrier are they with? Maybe there would be a cheap way for them to add another sim to their plan...

After that put in writing what temp/smoke level that you want the device to trigger at and the way you want to send the sms
 
This questions vague. In a large project you tend to think initially of generalized terms.
Example:
Boss wanted a printout after each test.

During development, it was shown that it was impossible to do so. It took too long for the laser printer to warm up. We then adopted batch printing. The side effect of the batch printing was that errors could be corrected because of the program design. You could load the data, modify it and save it. One particular variable area, actually scaled the data.

You did have to manually modify one of the files that controlled the printing. We printed the J-V curve of the "best" cell on a piece and the summary of all of the other cells.

Area was the hardest thing to change and we always tested with a "nominal" area.

The other thing we did when developing is to get approval of the main screen almost to the point the boss thought the program was done.

I designed the program so it operated in "simulation mode" from the get go. No working instruments, you would enter simulation mode. It saved a lot of development time.
 

Thread Starter

Pushkar1

Joined Apr 5, 2021
328
Okay, so... the client has come to you and said that they need a device that does that.

First thing is to in plain language go through the assumptions verbally, taking notes. I would start with, "You want an SMS when there is a fire detected, right?"

You need to do a bit of research and work out what temperature and smoke detectors are usually spec'd at.

You then need to have a look into what phone networks and what providers are available where the client wishes to use the product. What carrier are they with? Maybe there would be a cheap way for them to add another sim to their plan...

After that put in writing what temp/smoke level that you want the device to trigger at and the way you want to send the sms
OK, now I understand the problem statement nothing it's just detail description to develop the product before to start programming.

Kudos to papabrao, clck_here, and other members
 
Last edited:

KeithWalker

Joined Jul 10, 2017
1,947
We called that a project overview. It was a no-technical description of the proposal, to describe it to low tech management and budgeting staff. It was the introduction to the full project proposal which included specification of all the technical details, the cost analysis and the terms and conditions.
A problem statement was only ever produced if the project was to make changes to an existing system. It was a description of why the system needed to be modified.
 

Yaakov

Joined Jan 27, 2019
3,615
In my career I have used a lightweight version of Use Case Methodology which depends on descriptions of the function to the system from the point of view of users. This means using vocabulary naturally used by that population rather than technical terms from the domain fo the systems designers or novel, invented terminology unique to the system.

While it might seem unimportant, this last part has, in my experience, been critical to success. By properly naming parts and functions of the system, it is possible to understand what the scope and actions of the system parts must be.

This also drives the naming of variables, subroutines, fields, and tables. In my most successful projects this worked so well that many times feature requests were answered by "it already does that check the documentation" or simple additions in the form of "glue" rather than new system components.
 
Top