As a non-technical client, how is a requirement for a custom-built software produced?

Question

I'm a software developer joining a Finance Department to look into some of the problems they're having, and one of which is a custom software vendor hired to create an RPA (Robotics Process Automation) robot.

The vendor is now arguing that their software has "met the requirements" of what is asked, even though there are clearly things that are beyond the scope of the understanding of the Finance department.

One is the issue with data types and numbers. Excel was producing numbers with 9+ decimal places (e.g.: 0.000000009), which was being displayed as "0.00" when filtered as an accounting number, but now the vendor argues that these very small numbers are "not zero" and their program is "correctly filtering out 0s".

I also realized that since I have a technical background, I never had to worry about dealing with these issues, but how would a non-technical client usually approach a software vendor and produce a useful requirements that prevents these "technically correct" but functionally wrong results?

Answer 1

First point - I'm siding with the Software Vendor here. Either you didn't scope the project properly or you have crap input data. If the value should be '0', but it is being entered as 0.00000000009 - then that is not 0.

Not their fault, if you want to change the scope of the project, you should pay them. Or you should fix the input data, if it should be 0, make it actually 0.

To Answer the Question though

This is sadly a common occurrence - things that a human can 'filter' out and 'fix' on the fly, can require a lot of logic to handle and something that non-technical people can often fail to appreciate.

The only way to handle this is an iterative process, with key test points and agreed metrics.

The Sample data used for the development of the tool should have been representative of the real world data and this should have been picked up. If the client signed off the sample data, without properly evaluating the output - then that's on the Client.

There's no other real way to handle it.

Answer 2

Obviously, filtering out zeroes should not filter out values that are not in fact zero. The problem here is that amateurs are working with Excel without understanding it. A finance department of all places should be well aware that the digits after the decimal point count, not matter how far after the decimal point.

But that is not the workplace problem. Well, it might be one, but one you didn't ask about.

There are two types of companies: those that think everybody can read their minds and craft a contract, so when that mind reading mysteriously fails, they can assign blame and make sure it's somebody's fault and someone pays. And then there are companies that collaborate and try to get the best result in an imperfect world.

The first type of company is left with a crappy piece of software that does not work, legal bills, court appointments and litigation over years and years. And all the time, their core business is running on broken software. Obviously they need a new contractor for each project, that again will not understand what they want, because not only are their mind reading capabilities limited, but they are new.

The other type of company will have a piece of working software for the requirements they had. They will improve on it or start another project with the contractor, that is now proven to do a good job and already has more experience in their business and their needs. While they might have gotten their software project for a higher price than the first company, the savings in lawyers and constantly changing contractors and the fact that their software actually works and they make good money in their core business makes it the better package deal though.

Your company is stuck in the first "contract & blame" mode. And that is systemic, it already crafted the requirements with "contract & blame" mode in mind. Because as you experience right now, it's not about fixing the problem, it's about who's fault it was and who needs to pay for it.

Good companies do not just put "requirements" out there. Good companies will have "acceptance tests" for each requirement, so that not only can you objectively test whether the software fulfills it, you can also test early and if the test shows that the requirement is not what was expected, you can change the requirement very early in develepment, where it costs very little.

As an example for your requirement, there should have been an acceptance test that read:

With the attached testdata.xls the process should frobicate 15 widgets, 13 of which are in yellow, 2 in red. 3 widgets will not be frobicated at all, because they will be filtered out.

And then when the developers run the excel file, it will be clear nothing is filtered out.

Then people will meet, talk and find a solution. Maybe the solution is to filter out everything smaller than $0.01. Or something else. Anyway, they can see how much it costs, it will probably not worth talking about the price, because two managers haggling over the price will cost more than the developer fixing it.

Point here is: there is no need for blame or finding fault, both parties did not think about this case, as evidenced by the fact that such a case was not brought up by either party as a test case.

Your company can either stay in "contract & blame" mode or they can start growing into a functional business and collaborate with their partners for mutual gain.

Acceptance Tests are one part of doing so. An open mind and looking at the benefits first, not the costs is another.

Answer 3

Developing the requirements should have been an iterative discussion with the vendor.

There should have been checkpoints along the way to confirm that what they were doing was in fact what you wanted done.

I can't entirely fault them for wanting to be paid for a small number of additional hours to clean up if your spec really was fuzzy despite having gone through the above. On the other hand, as customer I'd tell them that I'm not going to hesitate to speak publicly about my experience with them, and it's up to them to decide what kind of reputation they want to earn.

One doesn't have to be technical to apply any of these steps. And in fact the vendor should have been helping you drive toward the first two. "I didn't understand because I didn't ask" is not a defense.