Questions "What? Where? When? ”In functional requirements

A look at the functional requirements for an integration system

Probably all developers had to deal with both wonderful and disgusting system requirements. Each industry has its own specifics and universal standards can be defined only on paper. And when real standards are written according to these standards, we get the hundred-page documents “nothing”, which at best do not interfere with the development, and often - mislead about the real needs of the user and customer.

Therefore, in this post I will try to briefly express my thought regarding the definition of requirements specifically for integration systems . I ask you not to consider the idea in a different context, otherwise the post will seem to be nonsense, and I will be an idiot.

The main goal of any integration system is to provide information to end systems and users. This information must be complete and accurate. It should be presented in the right format for the user or system. She must act on time. It should be clear and sufficient for work. Therefore, before you write the first line of code or install the first application you need to answer a number of questions.

What?

What information do users and systems need? An accountant will not be able to work if he does not report all cash transactions. The client will not be able to make a purchase in the online store, if he does not know the cost and characteristics of the purchased goods. The delivery service will not bring anything anywhere unless they are informed of the addresses of customers. And the CEO is unlikely to make at least one adequate decision if he does not see a clear picture of the entire activity of the enterprise. Therefore, the first thing to do is to find out who needs what information to work with. Carefully find out, and then clarify again.
')

Where?

Where to get the necessary information and where to provide it? The accountant works with ERP and wants to see all the details in it. The director prefers to view reports in Excel files, and the buyer uses only the online store. None of them wants to sort through various sources of information, make clarifying calls and find out additional details by e-mail. They want to get everything they need in their familiar interface.

When?

We should not just collect all the data and provide it to end users or systems. We have to do it on time. If the data necessary for the construction of the quarterly report is delayed for a couple of days, they will be completely unnecessary. If the client has to wait a couple of minutes before he sees the price of the product and the quantity in stock - he will most likely go to a more agile competitor.
The question of "when?" Applies the rule of punctuality, which works in both directions. Those. the data should not be delayed, but cannot be transferred in advance if this is not necessary. No, nothing terrible will happen if we find out today what we need only tomorrow. But a clear understanding of how often we need to transmit information, what is its real volume, how critical is the efficiency, etc. - This is the key to choosing the right integration technology. And an incorrectly chosen technology is an overspending of the budget, a “broken” project deadline, an architecture far-fetched and omnipresent “crutches”.

By answering these three basic questions, and (most importantly!) Fixing everything in the documentation, you can begin to think about architecture and the technologies used.

According to the rules, these questions should be answered by “Functional requirements for the system”. It is also “FT”, or “Requirements specification”. In different companies, this wonderful document may be called differently, but the essence is the same - it determines what the system should actually do, and why do we need it at all? So, if FT does not answer these three magic questions - you can safely throw it away. To develop an architecture for such a document is impossible. It doesn’t matter how detailed the ordering process is, or how beautifully the administrative panel buttons are drawn - the document must be appropriate for its intended purpose. And to answer the questions put before him.

PS
And, yes, when someone writes FT, do not forget - every time a programmer gets a useless document, he painfully kills a little white rabbit!