Something I hear far too often – and most recently just this Friday past from a member of senior management that should know better – is talking about all requirements as either being “technical requirements” or “business requirements”, where business requirements are those that are important to the business aspect such as increasing profit or improving customer satisfaction, and technical requirements are those that are grounded in a technical base such as the need to support a particular platform or a demand for a specific interface to other systems.
The specific case on Friday was when I was talking about a part of my role being “maintaining a coherent and comprehensive understanding of the requirements of the users of our solution platform APIs”, to which the question was asked whether I am talking about business requirements or technical requirements.
This distinction is not only wrong and unhelpful, but in fact dangerous and negative to the operation of the business as a whole. It pushes a separation that does not exist, assuming that ‘technical’ people and ‘business’ people have differing goals and that the business people keep the business running, while the technical people make sure everything keeps working. This non-existent separation leads to technical people being ignored or otherwise not listened to when commenting on business matters; and further to business people assuming that technical implementation isn’t business critical and can safely be left to ‘the techies’ without consideration at a business level.
The last time I checked, “making sure that everything keeps working” is a pretty important facet of the business. Aside from this though, the simple fact is that every business decision in a technical organisation is a technical decision, and every technical decision carried out in a business is a business decision.
An example of the lack of consideration for technical implementation that shocked (and to be honest, frightened) me not so long ago was in a meeting at the end of an ideation project, where a member of senior management (a different one to the one mentioned at the start of this post!) claimed – quite offhandedly – that since a great idea had been created, we were already most of the way to having the product. This manager assumed that without having even drawn a single wireframe, sketched a single rough workflow, or written a single user story, that we could hand the idea – with a pretty mock-up video – over to a development group who would, with no further input, create the product he now envisioned in his head based on what he’d been shown.
I’m a creator. A software developer who has worn many hats from 3rd level IT systems support (with quick ad-hoc code to solve issues) through developer support, classic developer role, architecture and design for small projects, product management, team/department management, and finally now in to solutions architecture on a large and complex project. So, when I talk about ‘requirements’, I naturally talk about it from the perspective that I have from this background, but the fact is that that background gives a different perspective than many seem to assume.
Developers and other creators are business people. Technical people are business people. Attempting to make a distinction between the two is artificial.
When I design a piece of software, I do it to meet the business needs. The requirements given to me may be functional requirements – “what the product should do” – or non-functional requirements – “how the product should behave” – but either way, they are both technical requirements in that they must be implemented in technology as well as being business requirements in that they are being required because of business needs.
Throughout this piece, I’m not trying to say that the term “business requirement” has no use. It most certainly does. I’m actually more arguing the point that the term “technical requirement” has no use, as business requirements can be broken down to the functional and non-functional requirements as a more detailed (and perhaps ‘technical’) view of the larger business requirements. The point is that they’re not distinct and separate entities, but rather different views of the exact same thing.
There are some things that seem on their face to be more purely technical requirements. For example, if a particular system library that will help perform the operation needed is currently only available on 64bit Linux systems, it might be easy to say that there is a technical requirement for 64bit Linux on the product. It was never specifically requested by the customer, but is nevertheless required.
Note though that this requirement is still based on the fact that a particular operation is needed. This operation being requested is a requirement for the business. We could fulfil it either by sticking to a 64bit Linux platform or recreating the functionality of the needed library on another platform by perhaps porting it or even rewriting it in part or full. The former gives us a technological constraint (again, not a requirement), the latter increases time, effort, and therefore cost. Which we ultimately choose is a business decision.
Going back to the question I was asked on Friday, we start to see more clearly how the question itself doesn’t make sense. If we were talking about technological constraints, this isn’t something we need to continually update – our APIs (like any APIs) do have some specific constraints, but they don’t change with time or need significant management and maintenance. Clearly, I was talking about the functional and non-functional requirements that people who use our APIs have in order to deliver the products that they are trying to deliver. As the APIs are our products, their requirements become our requirements. Trying to call them “technical requirements” or “business requirements” is missing the point.
Another type of requirement that often gets misunderstood in this false dichotomy are internal requirements – especially those that are non-functional in nature. A good example of this is the requirement for maintainable source code. Our customer never requested this, and a short-sighted management is unlikely to know or care about how maintainable our code is, so it seems like only the technical people really push for this. Surely this can’t be a business requirement as well?
Of course it is! If the code is hard to maintain then the next time we want to do an update, it will take much longer and cost much more than it otherwise should. Developer morale will be lower having to work on fixing and patching bad code instead of new and interesting features and in the worst case, it can even lead to higher employee turnover, increasing costs and time even further due to retraining and other costs associated with hiring new employees. It may be an internal business requirement rather than an external one, but it’s still very much a business requirement.
As mentioned earlier, requirements are more properly and usually broken in to “functional requirements” and “non-functional requirements”. It can be tempting for those that like the false dichotomy to use these as an easy split for technical vs business. However, this more accepted division is actually also somewhat ‘faked’ and arbitrary at a deeper level.
Non-functional requirements talk about things like meeting a certain level of uptime, having particular security models, meeting certain user experience standards, and so on. Actually implementing any of these things comes down to choices about functional behaviour in the code. We make the distinction not because it has meaning at a deep level, but rather because it has distinction at the level of what the requirement is and what the customer ultimately cares about. The customer asks for and cares about 99.8% or better uptime, they don’t really care so much how that is achieved as long as it doesn’t conflict with other requirements such as cost (redundant servers with good failover code help ensure high uptime, but at a much higher cost). But in the end, it’s still specific functionality (such as the failover code) that will actually achieve this.
The exact same thing can be said of all requirements of the product, regardless of which area it comes from. Different licensing options? Sure, it’s a business decision which will be implemented, but it’s still down to the code to make sure it goes in. Different mobile device platforms for a new game you’re building? It may be easier to choose one or another, or even an abstraction layer, but ultimately it’s a business decision based on what end-users your customer wants to reach balanced against differing effort levels (read: “time/cost” as always) to provide it.
I am regularly involved in discussions about needs for a new function to be added to the products produced by our parent company. A good example of where this incorrect understanding can cause problems is from many years ago during one such discussion. The request was for the possibility for a user to enter additional metadata during a process based on previously entered data but before the process runs in full. That is, an optional ‘second step’ of data entry before processing takes place. Use cases were written and after agreement it was submitted to the development team. Unfortunately, the developers themselves had not been involved in the discussion and only saw the use cases. These had been written by people that believe that implementation details are not relevant to business and so were written to a very high level only. The result was that what we got from the developers was a second data entry stage as requested, but one that had to be predefined in advance and could not be dynamically generated based on the first round of data entry. It fulfilled the use cases as written, but didn’t actually meet the needs of our customers that had been requesting this functionality.
Thoughts on anything and everything 