If you have a team in your company, it is (hopefully) stocked with highly trained that are well paid and know what they are doing, or know how to figure out what to do in a timely manner. They offer the best value for money to your company when they are empowered to make technical decisions, after all, if they are not the technical authority in the company, then what are they there for?

It doesn’t make much difference if the company is an ISV or an internal IT department serving internal customers only. At the end of the day, you have a software team serving customers by providing software based solutions to their problems.

The customer’s role is to provide what are normally called “user requirements” or “functional requirements” – in other words they need to tell the software team what it is that they want the software to actually do for them. It stands to reason that the customer is the best person to ask what the software they are asking for should do.

Now, it is very common that the customer struggles to tell the software team what it is they want. Either they really don’t know, or they think they know but turn out to be wrong. Both of these “incomplete requirements” scenarios can be handled using an development process so they should not present a big hurdle for a competent team. The basic premise still remains, the customer’s job is to provide functional requirements, no matter if they give them all up front, or piecemeal along the way.

From those requirements, the software team is charged to implement a solution that implements those functional requirements. As I proposed above, a software team designing and implementing software is the highest and best use of their time. So this scenario sounds like the perfect environment for quality software to thrive.

Of course finding a company that fosters this environment can be hard. Often the culprit that violates this nirvana of quality software is the customer that doesn’t quite know where their responsibilities begin and end. You can smell this happening when functional requirements documents contain statements that refer to specific technologies or architectures. For example, a functional requirement that states “The UI will be implemented using technology ‘X‘ because it is the only one that can handle the requirements” should be an immediate alarm bell. It seems benign, but there are many problems that can manifest from a requirement like this.

The obvious first problem is you have a group who are not the technical authority making technical decisions. This is a political, social and morale issue. Technical people like making technical decisions, that’s why they are technical people and not or sales people. If you take away their ability to make technical decisions they are likely to resent it, their buy-in for the project will drop, the morale will drop and the result will be an inherently lower quality output.

Another problem is that you have less qualified people making technical decisions. If your customer is more technically qualified than your software team, you are probably doomed before you begin. If this is the case for you, forget reading the rest of this article and start polishing your . A good software team should contain members that are relentlessly exploring new technologies and trends. Without question your software team will have a deeper knowledge of all possible choices and the ramifications of one choice over another.

Software contain a lot of knowledge that is not necessarily written down in policies, procedures or architecture documents. This latent knowledge base is the main value of the team. It would be impossible for an outsider to posses most of this knowledge, particularly the knowledge that is specific to this team as opposed to software in general. The reasons behind certain tradeoffs made 2 releases ago can be a critical knowledge point to have.

This latent knowledge is a double edged sword though. I have seen many meetings between customers and engineers where an engineer will discount a suggestion from the customer, and when the customer asks why the engineer struggles to answer even though he has the knowledge. I like to think of it like breathing. You know that breathing is remarkably important, in fact you do it all the time and you really couldn’t imagine doing anything else. And yet if someone asked you how to breathe, it is quite difficult to explain, particularly if you are talking to an alien that doesn’t have lungs and doesn’t understand the basics of human respiration. Well that might be taking it too far, but the point is valuable. Another analogy is a human trying to explain their existence to an ant. Ignoring the obvious communication issue, the conceptual argument offered by the human is completely incomprehensible to the ant because his reality is so different to the human. So basically, trying to explain software development to a layman is often difficult simply because you have no common reference point and no common language to use. If you try, you will often cause more harm than good.

So is there a time when a customer should define technical requirements? The answer is a definite yes, with a closely followed maybe. A customer can have legitimate constraints that need to be observed. Call them “environmental requirements”. For example, needing the software to run in a Windows environment because that is all the customer has on their 2000 desktops, is a reasonable requirement for the customer to have.

A requirement stating that the software must be browser-based because the customer’s IT department doesn’t want to have to install the software on the 2000 desktops also sounds reasonable. But then the question for the software team is, what does “browser-based” really mean? What if the software could be developed using something like Java WebStart (a sort of browser/thick client hybrid), is that going to be acceptable? What if the software is inherently better delivered that way because of the rich UI that is possible? Clearly this second requirement could restrict the choices of the software team to the extent that the quality of the solution may be affected. The key is to get at the true underlying requirement. If the requirement was restated as “The solution should have a zero-install profile to reduce TCO”, then the software team can achieve the requirement and still have their hands untied to find the best technical solution.

Is the opposite true? Can the software team impose functional requirements on the customer? Again the answer is a definite yes with a closely followed maybe. If the development process is one in which the requirements are written up front and development happens later, then input from the software team is very difficult to take into consideration. Don’t forget, the software team is usually the first ones to use the software being constructed as they test their . They will often find design defects very early on. Being able to provide that feedback to the customer is highly valuable. That value increases exponentially in an agile development environment where that feedback can be acted on quickly. In the end, the functionality needed is the customers decision, and suggestions from the software team may be ignored for very valid reasons. Software teams simply need to swallow that pill, you can lead a horse to water …

I have talked about the highest and best use of software development team resources, but the opposite is also true for the customer. If the customer manufactures fridges, then the highest and best use of their time is working with fridges. If the customer is the internal marketing team, then the highest and best use of their time is doing marketing things. If that isn’t the best use of their time, then they are on the wrong team.

The quality of the output of a software project is improved when customers and developers are aware of their responsibilities and work within them. The quality is improved exponentially when customers and developers are also given the ability to provide feedback in both directions and when the development process empowers both teams to act on the feedback quickly.