My Corner of the Web
Bottom Line Up Front (aka the Army version of "TL;DR"):
Since people don't often know what they want in software, use architectural views to avoid playing "Get me a Rock".
My son, Gregory, is a brand new junior software engineer and has recently learned a lot by a manager playing the "Get me a rock" game.
It goes like this:
Manager: "Get me a Rock"
Engineer: "Ok, what color Rock do you want?" Manager: "Oh, a bluish color or maybe green"
Engineer: "Ok, what size of Rock do you want?" Manager: "Well, not too large, but not too small"
Engineer: "Ok, what shape of Rock do you want?" Manager: "Something cool or interesting"
So, the engineer runs off and gets a blue, medium-sized rock with a triangular shape.
Engineer proudly says, "Here is your rock! It is blue, medium-sized and a very interesting, triangular shape"
The manager shakes his head, "No! No! No! That's NOT What I Want!"
So, the engineer runs off and gets a another rock, this time it is a green, smaller-than-medium, rectangular rock.
The Engineer again proudly says, "Here is your rock! It is definitely better and more interesting than the last one!"
The manager says sadly, "Well, nice try and you are getting warmer but it is not quite right. Try again."
So, the engineer sulks off and gets one more rock, this time it is greenish-blue, smaller-than-medium, arrow-head shaped rock.
The Engineer weakly says, "Here is the best rock I could find. It is the right color, shape and size."
The manager angrily says, "Were you even listening to me? Totally cold... you blew it! That is not at all what I wanted!"
Welcome to the Art & Science of Eliciting Requirements from Vague Specifications!
This is an important skill that EVERY software engineer needs to learn, in fact, actually every business person needs to learn this too because customers, senior managers, and even family and friends often given vague specifications of what they want.
The reality is that most people don't really know what they want - precisely. They function on general rules of the road like "better than before" or "something cheaper" or "higher quality" which are difficult to clarify. That leads us to the second key problem with providing requirements which is that most people cannot verbalize what they want even when they have a clear idea of it in their head. This phenomena I call the "Conceptual to Verbal Gap". Otherwise known as the "Gulf of Communication"!
So, how do we solve this?
The answer is to "Draw the Rock!"
The old adage "a picture is worth a thousand words" is true and especially useful in avoiding the "Get me a rock" game. This also honours the principle "I'll know it when I see it". The simple idea is that you create designs (aka architectural views) of the objective state. This is a form of envisioning that enables us to transition from the current state to our objective state. In Enterprise Architecture (EA) speak this translates to:
AS-IS ----- Plan ----> TO-BE
In other words, we design the TO-BE or objective state, we document the AS-IS (or current) state and then create a plan to transition us from one state to the other. This is usually captured in a document called a CONOPS for Concept of Operations.
This technique proved successful for my son (who created a data flow diagram) and it will be successful for you too! Best wishes!