Nowadays when we develop IT systems, we often do this based on an understanding about how the solution actually will be used and how they affect the business and the organisation.
And this is good.
The problem is just that we can easily forget the system in our eagerness to understand the needs of the business. This means that sometimes we do not check how our systems are thought to function and behave. Later on, I have often run into this problem, which can result in problems maintaining quality in the system over time, since it is harder to manage and further develop something that you don’t properly understand.
A system needs a long view
Do not misunderstand me, I think it is important to understand what value a solution will deliver to the business, and which requirements the business has for processes that create value, for example. This means that IT receives specification for being able to deliver solutions that effectively support the business. But at the same time, we don’t want systems that break after a while or become impossible to further develop.
Up until about ten years ago, we who worked with requirements tried to specify system requirements that should support the system from our role as system analysts in the IT organisations we worked in. The problem was often that there wasn’t a corresponding role within the business, and even if we specified and built good solutions, they weren’t always the solutions that the business needed. From our IT perspective, we saw only the IT parts of the solution and no one looked at the whole.
With time, many organisations recognised the problem and hired business analysts. Several of us who previously called ourselves requirement analysts or system analysts began instead to call ourselves business analysts. We read BABOK, brought out models for processes, concepts and information. We began to interest ourselves in what happened outside of the world of IT systems to try and bring about changes that did not just consist of IT systems.
System requirements has become a dirty word
In my opinion, this has gone a bit too far. Somewhere along the way, system requirements almost became a dirty word. Requirements should only be described from a business perspective and we should not spend more time on documenting detailed system requirements. Even if user stories are an excellent tool to research requirements, it is a very lousy format for documenting a solution.
The result of this is that you don’t have a clear picture of how the solutions you produce actually will behave. You hae an overall grasp of how they will support business processes, handle information and which business rules apply, but you lack a grasp of the details. Quite simply it is important to understand how a system will behave, even in detail. Similarly, the details about how a control unit in my car is constructed or function is not important for me to know as a car owner, but in order to get my car serviced, the details need to be specified and known by the garage.
In the same way, IT organisations almost always have a need to be able to know the details of how a system will behave. If you don’t have that, you can easily have problems further developing the system or to erify that it behaves as it should, above all when the system exists and is further developed a while. It is not easy to remember all details in something that is developed long ago, and it is uncommon that the people who developed the system are still there in a management organisation during the entire life cycle of the system.
We should also specify our systems more than what has become the norm in recent years.
Select a format that suits the need
The format of these specifications does not need to be in the form of what we normally call system requirements. Sometimes, technical design specifications, test cases or some other type of system documentation that meets the need can be enough.
I don’t think that these system requirements always need to be understandable for the business. There are business requirements described so that they can be used as a contract between IT and the business. System requirements then become an internal documentation for IT that suits the IT organisation’s needs. And the system requirements shall be managed and developed together with the system.
So even if it is good that we become cleverer at understanding the business needs behind the development, we should not forget the IT organisation’s needs to be able to ensure quality in the systems we develop and manage. And to succeed we need detailed system specifications.
Jakob Bäckström, consultant and partner Tagore