Have you experienced such stress in a real-world task and how did you get rid of it?
I hope that my question is OK, otherwise feel free to close it.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Have you experienced such stress in a real-world task and how did you get rid of it?
I hope that my question is OK, otherwise feel free to close it.
My understanding of the “Frame Problem” is that it relates to the removing the need to state implicit assumptions about the way the world works. In the example given here Moving an object doesn’t change its colour, painting an object doesn’t move it. “Obvious” to those familiar with the real world, but tedious to write down such assumptions. [And then we move an object into the paintpot, and lo! Its colour changed.]
I would say that the problem of agreeing what is “obvious” is endemic to every requirements gathering exercise. The Business person does not tell of a special case, because it is obvious that … they are not even aware of it being a special case.
Hence our job as producers of software is to get into that Frame of Reference, to really understand the problem domain. And it’s tough. I would say that improperly understood requirements are a very serious problem for a high proportion of projects. Great analysts are very good at teasing out the detail.