Importance of Software Requirement and Requirement Gathering

Business requirements for building an enterprise scale software apps are very crucial and critical for the business. Every IT professional is aware of the process of gathering requirements and its implications. Unfortunately, in my opinion, the cost of formulating an incorrect business rule and coding the rule is least understood by most IT professionals. The following is my experience of requirement fallacy.

My organization is providing health care services to disabled individuals. The IT division in my org is building apps to facilitate the other employees to handle the financial, medicare/medicaid, placement of the disabled. I am part of new project and we don't have a business analyst to gather the requirements (imho BA's are PRO for IT), so switched multiple hats (as usual) went straight to the stakeholder to get the required info. The stakeholder redirected to a specific employee to answer my questions. One of the main questions I had was

Can the benefit amount awarded to the client be split among entitled payees?
The reply was, yes the benefit amount comes in one check and is split among multiple payees.

Benefit Amount (ID  1) = $100
BenefitID 1 $X to Payee 1
BenefitID 1 $Y to Payee 2

So, took this reply and went to my team to discuss the implications because this was new information. The current database cannot handle the split amount of the benefit. For ex. the benefit could be $100 and is split $50 each if there were two payees.  We had about two months of intensive discussion on how to change the current asset table which houses all the benefit info of the client. Plan for how to change the front end screen to handle this new feature along with planned changes to the triggers and stored procs.

After 2 months we had a meeting again and I raised same to make sure we were on same page.  

Can the benefit amount awarded to the client be split among entitled payees?
The reply was, yes the benefit amount comes in one check and is split among multiple payees. The split is not on the entitled amount but it is as follows
Benefit ID1-a $X to Payee 1
Benefit ID1-b $Y to Payee 2
and its is not

This threw off the discussions to waste.  As most employees in IT are consultants, the IT management team successfully utilized the consultants time to design, build and  test an incorrect business requirement.

What can be the done to bridge the gap? Business communication is critical. Client may speak gibberish but they are always  correct because it makes sense to him/her. Its up to the translator to convert the gibberish  to proper sentences.   

Rule 1: Always double check the answers/business rules
Rule 2: Re ascertain yourself by asking  "is this what you are trying to say" or "Is my understanding of the situation correct?"
Rule 3: Try ask questions beginning with what/why/who/where/when and how

A part of software engineering is requirements gathering which form the basis for the software application.